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ABSTRACT 


This  paper  compares  the  performance  and  features  of  five  different  tools  for  object-oriented 
simulation.  Three  of  the  tools  (MODSIM II,  SES /workbench,  and  Sim++)  are  commercial 
products  that  are  targeted  exclusively  at  simulation  work.  Also  examined  are  simulations  in 
Smalltalk-80  and  our  own,  non-commercial  C++  simulation  library,  called  MOOSE  (MITRE 
Object-Oriented  Simulation  Executive).  For  each  of  the  tools,  we  discuss  the  support  for 
simulation,  the  support  for  object-oriented  design  and  the  degree  to  which  these  areas  are 
effectively  integrated.  We  report  the  results  of  performance  testing  of  the  tools  using  six 
concise  benchmarks,  each  devised  to  test  a  specific  feature,  and  one  larger  simulation,  devised 
to  compare  general  performance.  Also  included  are  partial  results  on  ERIC,  an  object-oriented 
simulation  tool  developed  at  Rome  Laboratories. 
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SECTION  1 


INTRODUCTION 


This  paper  compares  the  performance  and  features  of  six  different  tools  for  object-oriented 
simulation.  Three  of  the  tools  (MODSIM II,  SES/workbench,  and  Sim++)  are  commercial 
products  that  are  targeted  at  simulation  work.  We  also  examine  simulations  in  Smalltalk-80, 
ERIC,  and  our  own,  non-commercial  C++  simulation  library,  called  MOOSE  (MITRE  Object- 
Oriented  Simulation  Executive).  MOOSE  is  included  to  represent  a  simulation  system  coded 
quickly  (in  less  than  two  staff  months)  using  a  standard  object-oriented  programming  language 
without  explicit  simulation  support.  ERIC  was  a  late  addition  to  our  study,  at  the  request  of  its 
developers  at  Rome  Laboratories.  We  did  not  analyze  the  features  provided  by  it,  and  two  of 
the  benchmarks  were  not  completed  in  it. 

In  this  work,  we  focus  exclusively  on  languages  and  tools  that  provide  at  least  a  minimum 
amount  of  explicit  support  for  object  orientation.  The  advantages  of  object  orientation  as  a 
structuring  methodology  are,  by  now,  well-known.  However,  the  emphasis  in  object-oriented 
systems  on  making  decisions  at  run  time  can  result  in  significant  performance  overhead.  Our 
survey  attempts  to  evaluate  performance  of  the  systems  in  quantitative  terms,  and  to 
qualitatively  assess  the  success  of  the  merging  of  object  orientation  and  simulation  paradigms 
in  the  systems. 

We  designed  several  concise  benchmarks  to  compare  performance  of  particular  features,  and 
one  larger  simulation  to  compare  general  performance.  In  developing  the  benchmark  code,  we 
noted  significant  differences  between  tools  in  three  areas:  the  modeling  approach  encouraged 
or  required  by  the  tools,  the  degree  to  which  the  features  of  object-oriented  programming  are 
supported,  and  the  interaction  of  the  modeling  considerations  with  the  object-oriented  features. 

The  simulation  tools  that  we  consider  provide  and  support  a  variety  of  simulation  constructs. 
ERIC  provides  support  for  only  event-driven  simulation.  Two  of  our  benchmarks  require  a 
notion  of  interrupt,  which  is  best  understood  in  the  process-driven  approach  to  simulation,  and 
these  benchmarks  were  not  coded  in  ERIC.  For  Smalltalk- 80,  we  used  a  simulation  executive 
based  on  the  one  given  in  the  Smalltalk  “blue  book”  [Goldberg  83].  ParcPlace  Systems,  the 
developer  of  Smalltalk-80,  provides  no  explicit  support  for  simulation.  We  also  examined  the 
option  of  starting  from  an  object-oriented  programming  language,  and  building  a  simulation 
executive  of  our  own.  One  of  us  (Leivent)  designed  and  built  the  MOOSE  C++  library  for 
simulation.  The  design  and  implementation  of  MOOSE  were  undertaken  when  preliminary 
benchmarks  on  some  of  the  commercial  tools  suggested  that  they  could  not  handle  large 
simulation  applications  efficiently.  The  C++  language  was  chosen  for  MOOSE  because  it 
provides  a  rich  set  of  object-oriented  constructs  without  incurring  excessive  performance 
penalties.  The  MOOSE  system  provides  the  same  basic  simulation  primitives  as  the 
commercial  tools,  and  was  designed  to  have  a  programming  interface  somewhat  resembling 
that  of  MODSIM  II. 
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The  remainder  of  this  paper  is  organized  into  five  sections  and  several  appendices.  Section  2 
provides  a  discussion  of  issues  in  simulation  methodology  and  object-oriented  programming. 
Section  3  contains  short  descriptions  of  the  tools  that  we  used.  Section  4  describes  the 
benchmark  simulations.  Section  5  discusses  the  results  of  the  performance  testing.  Section  6 
provides  a  summary  and  concluding  remarks.  Finally,  for  each  tool,  the  benchmark  source 
code  has  been  included  in  an  appendix. 
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SECTION  2 


DESIGN  ISSUES 


Many  of  the  differences  between  object-oriented  simulation  systems  can  be  grouped  into  three 
areas:  the  modeling  approach  encouraged  by  or  necessary  to  use  the  tools,  the  degree  to  which 
the  features  of  object-oriented  programming  are  supported,  and  the  interaction  of  the  modeling 
considerations  with  the  object-oriented  features.  The  following  section  delineates  these  issues 
in  order  to  form  a  framework  for  the  discussion  of  tool  features  to  be  found  in  section  3. 


APPROACHES  TO  MODELING 
Event  Selection  Strategy 

Simulation  languages  have  been  characterized  successfully  by  event  selection  strategy  as:  event 
scheduling,  activity  scanning,  and  process  interaction  [Kiviat  71,  Fishman  73].  Figure  5  in 
[Hooper  86]  characterizes  these  strategies  in  detail.  Key  consequences  of  the  event  selection 
strategy  include: 

•  What  are  the  components  that  the  modeler  develops? 

•  How  is  the  state  of  the  simulation  components  expressed? 

•  How  do  the  components  interact  with  each  other  and  with  the  system,  i.e.,  what  is 
the  world  view  of  the  component? 

Earlier  simulation  languages  developed  in  the  United  States  implemented  the  event  scheduling 
strategy,  while  the  activity  scanning  strategy  gained  some  popularity  in  Europe.  Many  later 
simulation  languages  (and  later  versions  of  older  simulation  languages)  have  adopted  the 
process  interaction  strategy.  It  is  widely  recognized  that  the  process  interaction  strategy  results 
in  a  model  representation  that  is  “closer  to  the  problem”  and  thus  results  in  easier  and  more 
straightforward  model  development. 

This  correspondence  of  real-world  problem  to  expression  in  code  has  been  recognized  as  one 
of  the  advantages  of  Object-Oriented  Programming  (OOP).  This  is  not  a  coincidence  since 
much  of  the  early  motivation  for  OOP  can  be  attributed  to  Simula-67  (which  evolved  from  the 
simulation  language  Simula  I)  and  the  evolution  of  other  simulation  languages.  Thus,  it  should 
not  be  surprising  that  all  of  the  object-oriented  simulation  tools  examined  in  this  paper 
incorporate  the  process  interaction  strategy. 
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World  Views 


Certain  simulations,  such  as  the  bank  example  described  later,  differ  greatly  in  design  when 
written  with  the  different  tools,  despite  the  fact  that  all  of  the  tools  share  the  process  interaction 
strategy.  These  differences  arise  because  of  biases  toward  particular  design  decompositions 
(or  world-views)  that  are  either  supported  or  required  by  the  tools.  In  particular,  the 
identification  during  the  design  decomposition  of  active  versus  passive  components  varies 
according  to  the  tool  used. 

Active  components  are  defined  as  those  capable  of  initiating  activities,  while  passive 
components  are  incapable  of  initiating  activities.  Each  active  component  usually  has  its  own 
independent  time-line,  while  passive  components  usually  pass  time  only  in  a  synchrony  with 
an  active  component,  e.g.,  a  passive  resource  that  is  held  by  an  active  job.  Active  components 
usually  have  more  complicated  behaviors,  so  code  tends  to  be  concentrated  in  their 
representation. 

Bezivin  [87]  has  defined  two  extremes  of  object-oriented  decomposition.  In  one  extreme, 
which  we  will  call  entity-oriented ',  the  active  components  interact  by  exchanging  messages, 
which  are  the  passive  components.  In  the  thread-oriented  model,  the  active  components  may 
send  messages  to  the  passive  components,  but  not  vice-versa.  The  passive  components 
mediate  the  communication  between  active  components,  which  never  communicate  directly. 

As  an  example,  consider  modeling  a  road  traffic  simulation  problem.  The  entity-oriented 
approach  would  model  the  crossroads  as  objects  that  send  the  vehicles  as  messages  between 
them.  In  the  thread-oriented  approach,  the  vehicles  are  the  active  clients  of  the  crossroads  and 
make  decisions  to  go  from  one  crossroad  to  another. 

Development  of  an  entity-oriented  model  generally  begins  with  a  decomposition  of  the  system 
being  modeled  into  places  at  which  processing  is  done.  These  places,  also  called  entities  or 
nodes,  become  the  active  components  of  the  simulation.  The  events  or  transactions  that 
represent  the  interactions  of  the  entities  (the  work  flowing  through  them)  become  the  passive 
components  of  the  model.  Modeling  then  becomes  primarily  a  process  of  describing  precisely 
and  correctly  the  behavior  of  each  of  the  entities  in  response  to  all  of  the  possible  sequences  of 
stimuli,  although  some  consideration  must  also  be  given  to  the  information  carried  by  the 
events. 

In  contrast,  the  development  of  a  thread-oriented  model  concentrates  on  the  flow  of  processing 
through  the  system  being  modeled.  Consequently,  active  components  are  sometimes  called 
mobile  components,  while  passive  components  are  called  stationary  components  since  they  are 
used  to  represent  fixed  services  provided  to  active  components.  Once  the  major  processing 
threads  are  identified,  the  modeling  process  is  primarily  one  of  specifying  the  processing  steps 
taken  by  each  of  the  threads,  although  the  resources  or  services  acquired  by  the  active 
components  must  also  be  described. 
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The  distinction  between  these  two  approaches  may  not  yet  seem  significant  to  some  readers. 
Indeed,  the  authors  do  not  know  of  cases  of  systems  that  could  not  be  represented  in  either  of 
these  world-views.  However,  there  certainly  are  systems  for  which  one  of  the  approaches  is 
better  suited  than  the  other.  The  complexity  of  behavior  of  the  components  of  the  systems  and 
the  bias  of  the  approaches  to  providing  more  powerful  constructs  for  the  active  components 
than  for  passive  components  determines  the  suitability  of  one  approach  over  the  other. 

Cbnsider  two  seemingly  similar  problems:  the  road  traffic  problem  introduced  above  and  a 
train  traffic  problem.  In  the  road  traffic  problem,  the  driver  of  the  vehicles  makes  the  decisions 
as  to  which  route  to  take,  and  the  designations  of  vehicles  as  the  active  components  and  the 
crossroads  as  the  passive  components  are  most  natural.  However,  in  the  train  traffic  problem, 
the  state  of  the  switches  at  the  intersections  determines  the  route  of  the  train.  So,  it  seems  most 
natural  to  specify  the  switches  with  active  components  and  represent  the  trains  with  passive 
components. 

The  decomposition  strategies  discussed  above  are  the  extremes.  In  most  real-world  systems, 
the  distinction  of  active  and  passive  components  is  not  as  straightforward.  In  the  road  traffic 
problem  above,  the  presence  of  traffic  lights  would  certainly  affect  the  outcome  of  the 
simulation.  However,  the  state  of  the  light  cannot  be  said  to  be  an  inherent  part  of  the  behavior 
of  the  vehicle,  indicating  that  the  crossroad  should  be  able  to  initiate  activities  such  as  the 
release  of  vehicles  when  a  light  turns  green,  thus  indicating  that  the  cross-roads  should  also  be 
an  active  component.  But,  since  active  components  cannot  interact  directly  with  each  other, 
alternate  methods  are  usually  implemented.  Also  consider  the  train  traffic  problem.  To  say  that 
the  trains  are  completely  passive  ignores  the  fact  that  they  may  break  down  or  otherwise  deviate 
from  their  schedules. 

There  are  also  systems  for  which  identification  of  the  more  active  components  is  not  clear-cut. 
Delcambre  [90]  considers  an  apparel  manufacturing  operation  consisting  of  a  number  of 
workstations  containing  specialized  equipment,  a  number  of  employees  that  operate  the 
equipment  at  the  workstations  and  may  be  qualified  to  operate  only  certain  equipment,  and  job 
orders  that  specify  the  apparel  to  be  manufactured.  The  job  orders  contain  the  information  that 
is  used  to  determine  the  processing  steps  involved  in  completing  the  order.  Each  step  in  the 
processing  requires  a  workstation  with  the  appropriate  equipment  and  an  operator  skilled  in  the 
operation  of  the  equipment.  First,  consider  a  thread-oriented  model  of  this  problem.  The  job 
orders,  or  perhaps  more  precisely  the  jobs  themselves,  can  be  the  active  components  since  they 
specify  the  threads  of  processing  through  the  system.  The  workstations  are  obviously  passive 
components  that  perform  services  for  the  active  components.  The  workers,  however,  cannot 
be  easily  categorized.  To  the  job,  they  are  resources  that  must  be  acquired,  and  so  would  seem 
to  be  passive  components.  However,  they  are  active  with  respect  to  staffing  the  workstations 
since  they  are  constrained  by  their  qualifications,  implement  the  shop  manager's  scheduling 
policy  or  determine  their  own  work  preferences,  take  coffee  and  rest  room  breaks,  and 
generally  behave  in  ways  that  managers  abhor.  Forcing  the  developer  to  model  the  workers  as 
strictly  active  or  strictly  passive  forces  an  unnatural  structure  on  the  simulation  and  may  result 
in  ungainly  artifacts.  Attempting  to  apply  an  entirely  entity-oriented  decomposition  results  in 
the  same  dilemma,  even  though  the  assignment  of  the  other  components  would  be  the  reverse 
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of  that  in  the  thread-oriented  decomposition:  workstations  would  be  entities  sending  job-orders 
as  messages  to  each  other  after  completing  their  portion  of  the  job,  and  workers  would  still  be 
problematic. 

The  consequences  of  a  bias  toward  a  particular  world  view  are  significant  to  the  implementer. 
As  mentioned,  more  code  is  generally  written  for  active  components,  even  more  than  is  a 
natural  consequence  of  the  more  complex  behavior  of  the  more  active  components.  This  code 
may  also  have  to  include  artifacts  of  simulation  such  as  event  scheduling,  random  distribution 
generation,  and  data  collection. 

While  the  bias  of  a  tool  toward  a  particular  decomposition  strategy  may  determine  the  suitability 
of  the  tool  for  a  particular  problem,  the  flexibility  of  a  tool  in  accommodating  a  number  of 
decomposition  strategies  will  determine  its  usefulness  for  a  broad  range  of  problems.  The 
tools  evaluated  differ  both  in  their  bias  in  the  world-view  that  should  be  used  in  models 
developed  and  in  their  flexibility  in  supporting  the  different  world-views.  MODSIM II, 
MOOSE,  and  Smalltalk  are  thread-oriented,  while  Sim++  and  SES /workbench  are  entity- 
oriented.  Each  has  features  that  support  models  of  the  other  world  view  to  varying  extents. 
MODSIM  II  provides  trigger  objects  to  synchronize  two  active  components.  Stm++  events 
may  contain  C++  objects  with  their  own  methods.  SE S/worlcbench  transactions  contain  an 
identifier  that  other  transactions  may  use  to  specify  synchronization.  Smalltalk  is  unique  in  that 
it  is  completely  object-oriented  and  open.  It  can  be  modified  to  be  entity-oriented.  Generally, 
tools  that  are  less  biased  to  one  extreme  are  also  more  flexible. 

Other  consequences  of  a  bias  in  world  view  include  limitations  on  support  of  object-oriented 
development  and  the  ability  to  support  parallel  simulation  execution.  A  strong  distinction 
between  passive  and  active  components  may  weaken  the  passive  component's  role  as  a  “first- 
class”  object  in  the  development  process.  It  may  preclude  the  ability  to  derive  passive  objects 
by  inheritance  or  otherwise  customize  the  behavior  of  the  passive  components.  Most  attempts 
at  parallel  simulation  have  adopted  the  entity-oriented  world  view,  since  it  seems  to  result  in  a 
relatively  small  number  of  components  of  sufficiently  large  granularity  to  overwhelm 
communication  and  synchronization  overheads. 

The  event  selection  strategy  and  the  world  view  of  a  tool  combine  to  determine  the  overall 
modeling  approach  of  the  tool.  As  mentioned,  all  of  the  tools  we  investigated  incorporate  the 
process  interaction  strategy.  In  all  of  these  tools,  the  active  components  are  processes.  The 
simulation  primitives  available  to  these  processes  include  many  that  resemble  primitives  used  in 
parallel  programming,  such  as  synchronization,  interrupt,  and  delay  constructs. 
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SUPPORT  FOR  OBJECT  ORIENTED  DEVELOPMENT 


The  benefits  of  object-oriented  development  have  been  extensively  debated  in  the  literature. 
The  application  of  object-oriented  development  to  simulation  has  not  been  as  extensively 
examined,  and  has  generally  focussed  on  the  productivity  benefits  in  development  [Eldridge 
90].  The  benefits  of  object-orientation  in  the  modeling  process  have  recently  been  examined 
[Delcambre  90]. 

The  tools  evaluated  here  vary  widely  in  their  support  for  object-oriented  development.  They 
also  differ  greatly  in  the  integration  of  "programming  objects"  with  the  "simulation  processes." 

Integration  of  Objects  and  Simulation  Time 

Object-oriented  development  results  in  a  set  of  partitions  of  a  program’s  data  space  and 
execution  trace  that  are  called  objects.  The  benefit  of  the  object-oriented  paradigm  over  other 
module-based  paradigms  is  that  the  resulting  modules  include  both  data  and  the  code  to 
manipulate  that  data  together  to  form  abstract  data  types.  One  premise  of  object-oriented 
development  is  that  the  resulting  objects  encapsulating  the  abstract  data  types  are  safer  and  less 
likely  to  be  misused,  since  the  modules  are  more  cohesive  and  their  intent  is  captured 
abstractly.  Also,  the  objects  are  easy  to  modify  as  the  requirements  of  the  program  evolve  or 
become  better  refined.  The  process  of  design  in  object-oriented  development  has  as  a  goal  the 
delineation  of  the  objects  that  will  be  implemented  in  order  to  fulfill  the  requirements  of  the 
program.  Object-oriented  design  often  includes  a  modeling  process,  where  the  objects  in  tne 
real-world  problem  are  identified  and  abstracted  for  representation  in  code. 

Similarly,  modeling  in  the  process  interaction  approach  to  simulation  also  includes  the 
identification  of  the  real-world  components  of  the  system  being  modeled.  The  identified 
components  encapsulate  the  processes,  sequences  of  activities  necessary  to  perform  the  work 
of  the  system  being  modeled.  Each  process  contains  pieces  of  the  execution  trace  that 
represents  the  flow  of  simulation  time.  Execution  will  continue  within  one  process  as  long  as 
consecutive  steps  in  the  processing  of  the  system  can  occur  and  jump  to  other  processes  when 
the  next  processing  step  cannot  occur  in  the  current  process. 

While  the  similarities  between  the  two  design  processes  are  obvious,  the  differences  can  make 
simulation  development  more  difficult.  In  general,  one  cannot  simply  follow  one  of  the 
popular  object-oriented  design  techniques  and  then  add  the  simulation  considerations  later. 

One  reason  for  this  is  that  present  object-oriented  methods  are  based  on  a  static  semantics,  i.e., 
the  passage  of  time  is  only  a  side-effect  of  the  execution  of  the  functions  and  procedures  that 
act  on  the  objects.  Coordination  between  objects  results  only  from  a  need  of  one  object  to 
invoke  the  processing  encapsulated  within  another.  Newer  methodologies  are  starting  to 
incorporate  concurrent  semantics,  i.e.,  the  notion  that  there  may  be  several  concurrent  threads 
of  execution  that  must  be  synchronized  at  certain  points.  This  is  a  closer  match  to  the  approach 
of  process-interaction  simulation  design,  in  which  the  coordination  of  processes  is  required 
only  when  the  processes  must  synchronize  in  simulated  time. 
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This  interaction  of  object-oriented  design  and  process-oriented  design  results  in  restrictions  on 
where  object  boundaries  are  drawn,  on  which  modules  contain  the  time  lines,  and  how  each 
object  can  elapse  simulation  time.  Different  consequences  were  found  in  each  of  the  tools 
examined. 

Where  are  the  Boundaries? 

The  boundaries  between  objects  are  shaped  not  only  by  the  object-oriented  decomposition 
process  but  also  by  where  advances  in  simulation  time  occur.  As  an  example,  consider  a 
model  in  which  a  job  must  acquire  a  resource.  Since  it  is  presumed  that  the  resource  may  be 
acquired  by  a  number  of  jobs,  the  resource  has  its  own  flow  through  simulation  time,  i.e.,  it 
has  its  own  time-line  (at  least  conceptually  ;  it  may  be  modeled  as  being  atomically  attached  to 
the  time-line  of  its  acquirer).  Thus,  the  procedure  (or  method)  that  acquires  the  resource 
coordinates  across  time-lines  and  the  mechanics  of  the  discrete-event  semantics  must  be 
invoked.  The  visibility  of  these  mechanisms  differs  between  the  tools  examined.  At  one 
extreme,  MODSIM II  simply  requires  that  the  method  for  acquiring  a  resource  be  designated  as 
one  that  may  have  simulation  time  side  effects.  At  the  other  extreme,  Sim++  requires  the 
explicit  passing  of  an  event  from  one  process,  the  acquirer,  to  another,  the  resource.  In  the 
former  case,  the  method  for  acquiring  the  resource  appears  completely  as  part  of  the  resource. 
In  the  later  case,  portions  of  the  method  appear  in  two  entities.  Thus,  the  boundaries  between 
objects  are  drawn  differently  in  the  two  tools. 

Where  are  the  Time  Lines? 

The  interaction  of  the  simulated  time  lines  with  the  objects,  i.e.,  the  granularity  of  the  domains 
in  which  simulation  time  is  constant,  also  vary  considerably.  In  most  tools,  certain  objects  are 
designated  to  be  the  simulation-relevant  entities,  i.e.,  the  objects  that  define  the  simulation  time 
at  which  its  own  methods  and  the  methods  of  subsidiary  objects  execute.  However,  one  tool 
(MODSIM  II)  allows  each  method  to  have  its  own  time,  even  within  objects.  Thus,  an  object 
could  be  executing  each  of  its  methods  concurrently  in  simulation  time. 

What  Entities  Can  Elapse  Simulation  Time? 

A  related  consideration,  at  least  in  the  tools  in  which  there  are  simulation-relevant  entities  as 
opposed  to  other  entities,  is  whether  the  non-relevant  entities  can  cause  simulation  time  to  pass, 
and  if  so  in  what  domain.  The  solutions  vary  from  not  allowing  objects  that  are  not  simulation 
entities  to  pass  simulation  time  (SES /workbench),  to  allowing  non-relevant  objects  to  pass  time 
for  the  simulation  entity  which  directly  or  indirectly  invokes  the  object's  method  (Si'm++),  to 
allowing  each  method  to  affect  only  its  own  execution  trace  (MODSIM  II). 
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Inheritance 


Inheritance  is  the  most  popular  of  the  mechanisms  in  object-oriented  programming  (as 
distinguished  from  merely  object-oriented  design)  that  allow  related  sets  of  objects  to  share 
common  implementations  of  abstract  data  and  methods  and  to  customize  these  to  produce 
slighdy  different  behavior.  The  ideas  of  inheritance  are  borrowed  from  the  classification 
methods  of  biology  and  other  natural  sciences.  For  example,  the  attributes  of  an  animal  include 
producing  progeny  whereas  the  attributes  of  a  mammal  are  generally  specialized  to  include  live 
birth  from  the  mother  and  require  nourishment  of  the  young  with  secreted  milk.  The  software 
program  for  a  hospital  may  include  a  class  of  objects  representing  rooms,  that  have  attributes 
such  as  length  and  width  and  methods  such  as  assignment  of  a  patient  A  specialized  room 
would  directly  inherit  these  attributes  and  methods  unless  they  were  over-ridden.  For  example, 
an  isolation  room  would  have  the  inherited  attributes  of  length  and  width,  but  would  over-ride 
the  assignment  method  so  that  only  patients  that  have  been  determined  to  be  dangerously 
contagious  would  be  assigned  to  them.  The  mechanics  of  specifying  the  similarities  of  the 
specialized  room  to  any  other  room  and  of  differentiating  the  room  from  others  is  provided  by 
the  inheritance  mechanism  of  the  software  development  system. 

The  support  for  inheritance,  or  other  sharing  mechanism,  varies  within  the  tools.  Some  do  not 
support  any  sharing  mechanism  other  than  the  creation  of  a  number  of  instances  of  an  object, 
whereas  others  provide  full  support.  In  some  of  the  tools,  inheritance  is  complicated  by  the 
restriction  on  drawing  boundaries  between  objects.  If  we  return  to  the  resource  example 
above,  the  partition  of  the  "acquire"  method  across  two  simulation  objects  complicates  the 
derivation  of  a  subclass  of  the  resource  class. 

Multiple  inheritance  is  a  means  of  specifying  derivation  of  a  class  of  objects  from  two  or  more 
parent  classes.  Other  than  the  mechanics  of  specifying  this  inheritance,  the  issues  associated 
with  multiple  inheritance  include  resolution  of  conflicts  when  two  parents  provide  methods  or 
attributes  of  the  same  name.  Some  of  the  tools  examined  do  not  support  multiple  inheritance, 
while  those  that  do  differ  in  the  method  of  conflict  resolution. 

Strong  Types  and  Object-Orientation 

The  simulation  tools  we  have  investigated  fall  into  four  categories  with  respect  to  their  object- 
oriented  behavior.  Smalltalk  is  exclusively  object-oriented  (everything  is  an  object,  every  piece 
of  code  is  a  method)  and  has  no  typing  mechanism  for  variables.  The  C++  tools  (MOOSE  and 
Sim++)  are  object-oriented,  but  not  exclusively  (there  exist  data  representations  that  are  not 
objects;  there  are  pieces  of  code  that  are  not  methods)  and  have  a  strong  typing  mechanism  for 
variables.  MODSIM II  exhibits  a  subset  of  the  object-oriented  functionality  of  C++. 

SES /workbench  is  actually  object-based,  since  it  lacks  an  inheritance  mechanism. 

The  Smalltalk  style  of  object-oriented  programming  is  perhaps  the  oldest  and  most  well 
known.  Smalltalk’s  lack  of  any  typing  mechanism  for  variables  is  most  beneficial  in  the  areas 
of  rapid  prototyping  and  iterative  refinement  of  software.  Also,  there  is  little  argument  about 
the  elegance  of  the  non-typed  object-oriented  style:  Smalltalk’s  semantics  are  far  easier  to 
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understand  and  work  with  than  any  of  the  other  tools  studied  here.  However,  a  strong  typing 
mechanism  is  missed  in  the  areas  of  program  readability  and  understandability  and,  as  our 
benchmarks  show  quite  clearly,  performance. 

The  question  is,  when  a  strong  typing  mechanism  is  present,  is  the  loss  of  rapid 
programmability  and  refinability  worth  the  gain  in  performance.  As  is  demonstrated  by  our 
benchmarks,  the  performance  benefit  may  be  so  overwhelming  that  all  other  motivations  can  be 
suppressed.  This  is  especially  true  for  large  simulations.  For  smaller  simulations,  and 
especially  for  simulation  prototyping,  the  performance  benefits  may  not  be  so  overwhelming. 
The  degree  of  integration  of  strong  typing  into  the  object-oriented  constructs  in  the  C++  and 
MODSIM II  models  may  be  part  of  the  decision  of  which  tool  to  choose. 

The  lack  of  any  typing  semantics  in  Smalltalk  means  that  a  Smalltalk  variable  can  refer  to  any 
Smalltalk  object.  Furthermore,  messages  are  resolved  to  methods  based  solely  on  the  type  of 
the  destination  object,  and  this  resolution  is  always  done  at  run  time  (commonly  known  as  late 
binding).  This  variant  of  object-oriented  semantics  makes  the  implementation  of  generic 
structures,  such  as  collection  classes,  very  easy  and  natural. 

The  semantics  of  the  combination  of  strong  typing  and  object  orientedness  in  MODSIM  II 
basically  involves  the  limitation  of  the  values  of  variables  to  objects  having  a  specific  common 
ancestor  class.  A  variable  of  object  type  X  can  refer  to  object  Y  if  and  only  if  the  object  type  of 
object  Y  is  a  descendent  of  object  type  X.  There  is  a  single  type,  called  ANYOBJ,  to  which  a 
variable  can  be  typed  so  as  to  be  allowed  to  refer  to  any  object.  Assignments  between  variables 
of  type  ANYOBJ  and  variables  of  any  other  type  are  permitted.  However,  references  to  an 
object’s  instance  variables  and  methods  cannot  be  made  through  a  variable  of  type  ANYOBJ. 

The  purpose  of  MODSIM  II’s  strong  types  seems  to  be  related  to  the  software  engineering  goal 
of  program  clarity.  There  is  agreement  among  the  authors  that  MODSIM  II  does  accomplish 
this  goal  very  well  relative  to  the  other  tools  investigated  here.  However,  the  issues  of 
performance  and  ease  of  programming  are  not  similarly  addressed.  MODSIM  II  methods  are 
all  late  binding  despite  the  presence  of  strong  typing,  so  messages  are  less  efficient  than 
function  calls.  Also,  overriding  methods  in  subclasses  is  hindered  by  the  requirement  that  the 
signatures  of  the  overriding  and  overridden  methods  be  identical.  This  particular  rule  can 
complicate  the  process  of  extending  the  functionality  of  a  class  through  the  formation  of 
subclasses.  One  immediate  impact  is  that  the  object  initialization  method  Objlnit  cannot  have 
any  arguments,  making  it  much  less  useful  than  object  constructors  in  Smalltalk  and  C++. 

C++,  possibility  because  of  its  kinship  with  C,  focuses  primarily  on  how  strong  types  can 
increase  the  performance  of  object-oriented  programs.  Unlike  both  MODSIM  II  and  Smalltalk, 
most  methods  in  C++  are  early  binding,  allowing  the  compiler  to  translate  message  sends 
directly  into  function  calls  without  any  additional  run-time  search.  Late  binding  can  be 
achieved  through  the  use  of  virtual  methods  which  have  a  small  associated  performance 
penalty. 
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Unlike  MODSIM II,  C++  possesses  overloading  semantics,  which  allows  multiple  methods 
with  the  same  name  and  different  argument  signatures  to  exist  without  difficulty.  This  permits 
developers  of  subclasses  to  extend  the  functionality  of  superclasses  by  adding  and/or  changing 
arguments  when  overriding  methods.  A  further  advantage  of  overloading  is  the  ability  to 
overload  most  of  the  operators  in  C++,  including  arithmetic  and  logical  operators,  comparison 
operators,  the  assignment  operator,  dereference  operators,  and  the  function  application 
operator. 

Assigning  between  variables  of  different  class  types  in  C++  can  be  tricky.  The  actual  rule  for 
such  assignments  is  something  like:  assignment  between  variables  of  different  class  types  is 
permitted  directly  if  the  type  of  the  source  variable  (or  expression)  is  a  descendent  of  the  type 
of  the  destination  variable;  assignment  in  the  opposite  direction  from  ancestor  to  descendent  is 
possible  using  casting,  but  it  is  only  safe  if  the  destination  variable  type  is  a  leftmost  ancestor 
(either  the  first  listed  parent  class,  or  the  first  listed  parent  class  of  the  first  listed  parent  class, 
etc.)  of  the  object’s  class,  or  if  the  destination  variable  type  is  a  virtual  ancestor  of  the  object’s 
class.  This  rule  can  complicate  the  task  of  writing  fully  reusable  methods,  especially  for 
generic  structures  such  as  collections.  Other  rules  involving  class  typed  arguments  to  functions 
and  methods,  and  how  overloaded  calls  are  resolved,  are  also  complex.  In  fact,  one  rule  in 
C++  that  allows  a  derived  class  reference  (a  generalized  variable  of  a  descendent  class  type)  to 
be  implicitly  converted  to  a  public  base  class  reference  (a  generalized  variable  of  an  ancestor 
class  type)  allows  unsafe  assignments  to  be  performed  without  so  much  as  a  warning. 

Dynamic  Creation  of  Simulation  Objects 

Some  problems  are  best  modeled  with  models  that  require  the  creation  of  active  simulation 
components.  Consider  a  model  of  a  typical  multi-user  computer  system  where  programs  run 
within  operating  system  processes  on  processors.  Since  processes  are  created  dynamically  by 
the  operating  system  in  response  to  users  or  user  programs,  they  cannot  be  statically  created  at 
initialization  and  yet  are  complex  enough  that  they  should  have  their  own  associated  timeline. 
Thus,  it  might  be  important  to  the  modeler  to  have  the  capability  to  dynamically  create 
simulation  objects. 

Two  of  the  tools  (S/m++  and  SES/workbench)  have  re:..  ions  that  prohibit  the  creation  of 
simulation  objects  after  either  development  or  after  an  iiaudl  phase.  Not  coincidentally,  these 
tools  are  also  the  ones  that  are  most  entity-oriented. 
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SIMULATION  CONSTRUCTS 
Time  Control 

It  is  a  tautology  to  say  that  time  control  mechanisms  are  required  for  simulation.  However, 
there  have  been  a  wide  range  of  time  control  mechanisms  implemented  in  different  simulation 
languages.  Much  of  the  difference  in  these  mechanisms  is  directly  attributable  to  differences  in 
either  the  event  selection  strategy  or  the  world-view  supported  by  the  modeling  tool.  These 
considerations  have  already  been  discussed. 

All  of  the  tools  examined  provide  time  control  mechanisms  that  are  more  than  adequate  for  any 
problem  which  we  were  able  to  conceive. 

Time  control  mechanisms  differ  markedly  in  their  visibility,  however.  In  some  tools  the 
passing  of  events  is  explicit,  while  others  hide  some  events,  such  as  the  completion  of  a  hold, 
and  in  others  events  are  never  visible. 

Preemption 

One  important  time-control  mechanism  that  caused  some  trouble  in  earlier  simulation  languages 
is  the  ability  to  preempt  or  interrupt  a  process  after  it  has  started.  This  capability  has  a  broad 
range  of  applications. 

The  support  for  preemption,  like  other  time  control  issues,  is  tied  up  with  the  other  modeling 
concerns.  The  tools  have  widely  different  implementation  mechanisms. 

Pre- Defined  Classes 

Pre-defined  classes  can  be  used  to  represent  parts  of  the  modeled  system  that  conform  to  the 
behavior  defined  by  the  class.  These  pre-defined  classes,  when  they  can  be  used,  cut 
development  time  and  size.  If  the  extensibility  of  the  tool  is  restricted,  as  discussed  below,  the 
pre-defined  classes  may  define  the  range  of  applicability  of  the  tool. 

All  tools  that  favor  the  thread-oriented  decomposition  provide  a  resource  class.  A  resource  is  a 
depository  of  a  number  of  tokens  that  can  be  acquired,  held,  and  given  back  either  singly  or 
multiply.  An  attempt  to  acquire  one  or  more  tokens  when  the  requested  number  are  not 
available  results  in  the  blocking  (in  simulation  time)  of  the  acquirer. 

The  tools  differ  in  number  and  types  of  pre-defined  classes.  This  is  discussed  further  in  the 
next  section,  where  we  cover  the  tools  individually. 
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Probability  Distributions 

Random  number  generation  is  an  important  part  of  most  simulations.  The  tools  examined  vary 
only  slightly  in  the  number  and  types  of  random  distributions  provided.  We  did  not  undertake 
any  evaluation  of  the  quality  of  the  generators.  During  our  benchmarking,  we  did  experience  a 
problem  with  random  number  generation  in  Smalltalk-80.  A  distribution  which  should  have 
returned  only  positive  numbers  returned  zero  on  occasion,  presumably  due  to  round-off  error. 

Data  Collection 

Data  collection  support  includes  support  for  accumulation  of  statistical  data,  statistical  analysis, 
and  I/O  operations  to  allow  archives.  All  of  the  commercial  tools  examined  provide  very 
similar  capabilities.  Data  collection  in  MOOSE  is  not  implemented. 


EXTENSIBILITY 

The  history  of  simulation  tools  has  supported  two  trends:  the  extension  of  an  existing  general 
purpose  language  to  include  simulation  support,  or  the  creation  of  a  special-purpose  simulation 
language.  The  first  presumedly  provides  greater  extensibility,  while  the  latter  presumedly 
provides  greater  integration  and  ease  of  use. 

Different  problems  require  different  degrees  of  extensibility.  Of  the  tools  examined,  three 
(Smalltalk,  Sim++,  MOOSE)  are  extensions  of  existing  general-purpose  languages,  while  the 
others  (MODSIM  n,  SES/workbench)  are  simulation-specific  developments.  Of  these,  one  is 
claiming  to  be  robust  enough  for  general  purpose  use,  while  the  other  is  extensible  through  its 
own  language  or  through  its  translation  to  C. 


GRAPHICAL  INTERFACES  AND  ANIMATION 

Graphical  interfaces  are  being  used  in  simulation  in  both  the  development  process  and  in  the 
display  of  results.  SES/workbench  provides  a  graphical  interface  for  the  development  of 
models.  Instances  of  pre-defined  object  types  are  selected  from  a  palette,  positioned  within  a 
window,  and  connected  using  Macintosh-like  point- and-click  methods.  Pop-up  boxes  are 
provided  for  forms  that  further  parameterize  the  behavior  of  the  model  components.  The  latest 
release  of  SES /workbench  also  provides  animation  capability. 

MODSIM  II  provides  a  library  of  graphical  objects  which  can  be  used  to  animate  the  results  of 
the  simulation  or  to  present  the  results  in  graphs  or  other  presentation  graphics. 
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SECTION  3 


TOOLS 


Our  selection  of  tools  was  biased  by  what  was  already  available  at  our  corporation  and  what  we 
could  acquire  for  reasonable  cost  There  are  many  interesting  simulation  systems  that  we  did 
not  consider.  For  example,  SimKit  (with  KEE)  from  IntelliCorp  provides  a  wide  range  of 
simulation  and  expert  system  capability.  Also,  other  object-oriented  programming  languages, 
such  as  Eiffel  and  Simula,  have  not  been  considered.  LISP,  as  the  base  language  of  ERIC,  has 
been  involved  in  our  study,  but  only  to  a  limited  extent. 

In  the  subsections  below,  we  provide  a  summary  of  the  capabilities  of  the  commercial  products 
that  we  did  consider,  and  then  a  description  of  MOOSE. 


MODSIM  II 

MODSIM II  is  a  “general  purpose,  modular,  block-structured  high-level  programming 
language  which  provides  direct  support  for  object-oriented  programming  and  discrete-event 
simulation”  [Belanger  90a,  90b].  CACI  Products  Company  markets  MODSIM  II  as  the 
commercial  version  of  ModSim,  which  was  created  on  a  US  Army  contract.  Modula-2  was  the 
base  language  used  in  the  creation  of  ModSim. 

Simulation  in  MODSIM  II  is  thread-oriented.  Threads  are  created  by  specially  designated 
methods,  called  tell  methods.  A  tell  method  programs  the  events  that  will  occur  in  the  thread. 
Tell  methods  are  asynchronous  and  cannot  return  values;  when  one  is  called,  a  new  thread  is 
created  and  the  calling  unit  continues  its  execution.  Tell  methods  are  also  reentrant,  meaning 
that  a  new  thread  can  be  started  while  other  copies  are  running.  An  ask  method  is  the  more 
traditional  method  call,  in  that  the  calling  unit  waits  until  the  ask  method  completes.  One  of  the 
limitations  of  MODSIM  II  is  that  simulation  time  can  be  elapsed  only  directly  inside  tell 
methods.  Thus,  if  a  tell  method  calls  an  ask  method,  that  ask  method  cannot  directly  execute  a 
wait  statement. 

The  object-oriented  features  of  MODSIM  II  are  sometimes  restricted  to  agree  with  the  type 
structure.  In  particular,  a  method  can  only  be  overridden  by  another  method  taking  precisely 
the  same  arguments.  Multiple  inheritance  is  supported,  and  ambiguous  references  are  flagged 
as  errors. 

Code  in  MODSIM  II  is  written  in  separate  main,  definition  and  implementation  modules.  The 
system  comes  with  a  smart  compilation  tool,  mscomp,  that  can  build  a  complete  simulation 
from  a  main  module,  recompiling  and  linking  the  appropriate  submodules.  The  compiler  for 
MODSIM  II  generates  C  as  output. 
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One  of  the  unique  capabilities  of  MODSIM II  is  that  it  supports  an  interface  to  CACI’s  graphics 
package,  SIMGRAPHICS.  CACI  claims  that  animated  simulation  demonstrations  and 
interactive  I/O  are  facilitated  by  SIMGRAPHICS,  but  we  did  not  test  these  features. 


SES/WORKBENCH 

Scientific  and  Engineering  Software,  Inc.  (SES),  introduced  SES/workbench  in  March  of 
1989.  Workbench  is  based  heavily  on  queuing  theory,  having  evolved  from  the  earlier 
PAWS/GPSM  (Performance  Analyst’s  Workbench  System  /  Graphical  Programming  of 
Simulation  Models).  Our  tests  were  performed  using  release  1.11  of  Workbench,  which  was 
the  most  recent  version  until  February  1991,  when  Release  2.0  became  available.  Release  2.0 
reportedly  contains  animation  capability,  which  is  completely  missing  from  Release  1. 

A  unique  feature  of  SES/workbench  is  the  graphical  front  end,  SES  /design,  which  allows 
specification  of  a  simulation  without  programming.  In  SES  /design,  a  simulation  is  specified  as 
a  hierarchy  of  directed  graphs.  Simulation  threads  are  called  transactions  in  Workbench. 
Transactions  flow  along  arcs  in  the  directed  graph.  Nodes  in  the  graphs  can  manage 
transactions,  e.g.,  source  nodes,  which  create  transactions,  or  manage  resources,  e.g.,  allocate 
nodes,  where  a  transaction  queues  for  a  resource.  A  small  set  of  standard  predefined  nodes  is 
supplied,  together  with  a  user  node  that  must  be  coded  by  the  user  in  C.  The  events  in  a 
transaction  are  not  directly  programmed,  but  arise  as  the  transaction  traverses  the  graph.  For 
this  reason,  we  view  Workbench  as  entity-oriented.  Transactions,  however,  do  play  an 
important  role  in  Workbench.  Mechanisms  exist  for  naming  transactions  and  interrupting  them 
at  arbitrary  points  in  their  execution. 

The  graphs  created  by  SES/ design  are  stored  as  ASCII  files.  These  files  are  compiled  by 
Workbench  into  a  simulation  language,  SE S/sim.  This  language  is  a  superset  of  C,  containing 
extensions  that  were  influenced  by  PAWS  and  by  C++.  Users  can  program  directly  in  the 
simulation  language,  if  they  desire.  For  our  benchmarks,  we  used  the  graphical  interface.  Our 
main  complaint  is  the  difficulty  of  debugging.  Errors  in  the  graph  file  are  usually  not 
discovered  until  the  simulation  language  is  compiled  into  C.  The  generated  error  messages 
refer  to  line  numbers  in  the  machine-generated  simulation  language  file.  This  leaves  the  user 
with  the  problem  of  trying  to  trace  an  error  back  to  an  arc  or  node  in  the  graphical  input.  Some 
improvements  to  debugging  are  claimed  by  SES  for  Release  2.0. 

Object-orientation  is  not  an  emphasized  part  of  Workbench.  The  SES /sim  language  does 
contain  constructs  for  specifying  classes  and  creating  instances,  similar  to  C++.  The  SES /sim 
manual  lists  only  very  basic  facilities  for  object-orientation.  In  particular,  there  appears  to  be 
no  provision  for  declaring  base  classes  or  member  functions  to  be  public  or  private,  no 
friendship  mechanism,  no  operator  overloading  —  in  short,  most  of  the  more  elaborate 
constructs  of  C++  are  not  present.  The  object-oriented  features  that  do  exist  are  more  likely  to 
be  used  by  the  SES  tool  than  by  the  simulation  designer. 
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Sim+  + 


S/m++  is  a  C++  library  of  simulation  constructs  produced  by  Jade  Simulations  International 
Corporation  of  Calgary,  Canada.  The  unique  feature  of  Sim++  is  support  for  parallel 
execution  using  the  Time  Warp  Distributed  run-time  system.  The  later  versions  of  Sim++ 
require  Release  2.0  of  ATT  C++,  which  the  user  licenses  separately.  Jade  recommends  8 
nodes  as  the  minimum  reasonable  parallel  configuration.  Networks  of  Sun  -3  or  -4 
workstations,  the  BBN  Butterfly,  and  the  Meiko  Computing  Surface  transputer  array  are  the 
supported  hardware.  The  Distributed  run-time  environment  provides  deterministic  execution 
despite  being  distributed.  A  number  of  tools  are  provided  to  increase  execution  speed-up. 
Sim++  also  provides  an  Optimized  Sequential  run-time  executive  for  developing,  debugging, 
and  executing  simulations  on  a  single  machine.  The  optimization  removes  most  of  the 
execution  overhead  associated  with  parallel  execution. 

The  results  in  the  following  sections  were  obtained  by  using  Release  3.0  of  S/m++  on  a  single 
workstation  using  the  Optimized  Sequential  run-time  system.  While  it  might  be  expected  that 
the  emphasis  on  performance  of  the  sequential  executive  is  not  as  great  as  that  for  the 
distributed  executive,  and  that  the  benchmark  results  for  Sim++  might  suffer  as  a  result,  we  did 
not  use  the  distributed  executive  for  several  reasons.  First,  we  did  not  have  it  Second,  the 
single-feature  benchmarks  would  not  have  benefitted  from  parallel  execution.  Finally,  the 
characterization  of  the  performance  of  parallel  systems  is  more  complicated  in  general  and  was 
felt  to  be  beyond  the  resources  available. 

The  Sim++  simulation  approach  is  entity-oriented.  A  static  set  of  simulation  entities  is  created 
for  each  simulation  run  from  sub-classes  of  the  Sim++- provided  sim_entity  class.  These 
sim_entity  sub-classes  define  the  behavior  of  the  entities  in  response  to  receiving  (or  failing  to 
receive)  events.  Events  passed  between  entities  are  derived  from  the  simjevent  class  that 
includes  an  integer  field  for  event  typing  and  a  pointer  to  allow  inclusion  of  a  body  containing 
state  information  in  the  event  While  an  event  body  may  be  any  C++  object  there  is  no 
enforcement  of  consistency  between  the  integer  event  type  and  the  supplied  event  body.  This 
consideration  and  the  lack  of  a  mechanism  to  directly  tie  event  types  to  entity  methods  tends  to 
limit  the  usefulness  of  inheritance  to  defining  components  of  entities  and  events  rather  than 
whole  entities  or  events. 

Preemption  is  supported  by  a  Hold_For  construct  that  is  interrupted  by  either  any  event  or  an 
event  that  passes  a  selection  criterion.  Selection  criteria  include  any  combination  of  event 
originator,  event  type,  or  contents.  While  this  construct  may  not  be  as  readable  as  the  interrupt 
mechanism  in  MODSIM II,  it  may  be  more  flexible. 

While  there  is  no  pre-built  support  for  resources,  resource  and  consumer  classes  were  built 
fairly  simply  for  the  fourth  single-feature  benchmark  described  in  the  following  section.  These 
classes  used  the  Hold_For  construct.  Events  requesting  a  resource  were  deferred  while  a 
resource  was  held  by  another  requestor.  After  release,  the  next  requesting  event  is  selected 
from  the  system-managed  deferred  event  queue. 
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While  no  explicit  support  for  graphical  input  or  animation  was  provided,  the  multiple 
inheritance  feature  of  the  C++  base  of  Sim++  allows  easy  extension  by  integration  with  other 
libraries. 


SMALLTALK-80 

Smalltalk  is  a  general-purpose,  object-oriented  programming  language.  For  our  tests,  we  used 
Smalltalk-80,  a  product  of  ParcPlace  Systems.  We  had  access  to  Release  2.5  on  Macintosh 
hardware,  and  Release  4  (the  successor  to  2.5)  on  Sun  workstations.  A  collection  of 
simulation  constructs  for  Smalltalk  is  described  in  the  Smalltalk  “blue  book”  [Goldberg  83]  and 
is  implemented  in  Smalltalk-80.  The  constructs  encourage  the  thread-oriented  approach,  but 
the  entity-oriented  approach  can  also  be  used.  There  is  a  useful  and  general  approach  to 
passive  and  active  resources.  No  provision  is  made  for  interrupts,  but  this  was  easily  fixed. 
One  of  the  main  advantages  of  Smalltalk  is  the  open  nature  of  the  system,  with  full  source  code 
visible  to  the  user.  For  simulation,  the  event  queue  mechanisms  can  be  examined  and  changed, 
if  desired.  In  the  browser  tool,  we  were  able  to  add  interrupt  mechanisms  to  the  simulation 
constructs.  The  new  constructs  merged  seamlessly  into  the  existing  ones. 

There  are  three  possible  problem  areas  in  Smalltalk.  The  first,  and  most  important,  is  the 
performance  problem.  As  a  rough  rule  of  thumb  for  general  computing,  Smalltalk  is  about  one 
order  of  magnitude  slower  than  optimized  C  [Chambers  89].  Doyle’s  data  confirms  this  rule 
for  a  simulation  benchmark  [Doyle  90],  and  our  timing  studies  show  similar  results.  For 
simulations  where  performance  is  not  a  critical  factor,  Smalltalk  may  be  a  very  good  choice. 
The  second  potential  problem  is  the  lack  of  multiple  inheritance.  There  was  at  one  time  an 
experimental  implementation  of  multiple  inheritance  in  Smalltalk-80  [Boming  xx],  but  it  was 
eliminated  after  version  2.3.  Currently,  only  single  inheritance  is  supported  in  Smalltalk-80. 
The  third  potential  problem  is  the  Smalltalk  learning  curve.  The  programming  language  and 
environment  for  Smalltalk-80  form  a  uniquely  powerful  system.  The  time  required  to  become 
proficient  in  Smalltalk-80  is  undoubtedly  longer  than  that  for  MODSIM II  or  SES /workbench. 
The  investment  in  learning  time  pays  off  in  increased  capability. 

A  PROTOTYPE  C++  SIMULATION  LIBRARY  -  MOOSE 

MOOSE  is  a  C++  implementation  of  the  process  model  of  discrete  simulation.  This  model  is 
most  similar  to  the  MODSIM  II  model,  where  each  TELL  method  execution  is  a  process. 
However,  unlike  MODSIM  II,  simulation  processes  are  first  class  objects.  Like  MODSIM  II, 
MOOSE  supports  dynamic  creation  of  processes. 

The  programmer  interface  to  MOOSE  was  designed  to  be  similar  in  nature  to  that  of 
MODSIM  II  because  of  the  authors’  familiarity  with  that  tool,  and  because  of  MODSIM  IFs 
ease  of  programmability. 
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The  majority  of  functionality  within  MOOSE  is  provided  by  class  Process.  The  simulation 
programmer  is  expected  to  provide  subclasses  of  class  Process,  each  with  its  own  definition 
for  the  start()  virtual  function  member,  and  its  own  set  of  constructors.  The  arguments  to  a 
process  are  provided  through  the  constructors,  aid  are  stored  within  data  members  of  the 
process  object.  The  start()  member  function  is  called  by  the  process  scheduler  to  initiate  the 
process.  MOOSE  provides  several  scheduling  primitives  that  can  be  called  from  anywhere 
within  a  process’  execution. 

Processes  in  MOOSE  can  be  created  dynamically,  and  are  expected  to  have  varying  lifetimes. 
The  memory  consumed  by  a  MOOSE  process  is  reclaimed  when  the  process  terminates.  The 
MOOSE  programmer  is  protected  against  dangling  references  to  processes  that  have  been 
garbage  collected  after  termination  by  the  use  of  a  safe  referencing  scheme  implemented  by  the 
process  identifier  (PID)  class. 

MOOSE  is  implemented  using  only  portable  C++  functionality.  The  process  class  is 
implemented  using  the  setjmp  and  longjmp  functions  (from  the  standard  C  include  file 
setjmp.h)  to  create  coroutines  on  the  execution  stack.  Such  an  implementation  of  processes  can 
run  in  any  C++  environment.  However,  the  use  of  virtual  memory  machines  is  strongly 
recommended  for  simulations  of  any  significant  size  because  the  setjmp/longjmp  coroutining 
technique  uses  large  amounts  of  address  space  (the  system  allocates  4K  bytes  by  default  for 
each  process’  stack),  even  though  the  amount  of  virtual  memory  actually  used  may  be  low 
(many  processes  use  only  a  small  portion  of  their  stack). 

The  MOOSE  event  list  used  for  scheduling  processes  has  a  tightly  coded  heapsort-based 
priority  queue  implementation.  This  implementation  was  found  to  be  slightly  faster  on  both 
Sun-3s  and  Sun-4s  than  several  alternatives  in  the  O(NlogN)  category,  such  as  splay  trees  and 
leftist  trees.  The  heapsort  algorithm  is  array-based,  and  requires  that  the  heap  array  be 
allocated  statically.  However,  the  heap  array  is  reallocated  (using  the  realloc  function)  as 
needed.  The  additional  complexity  of  the  reallocation  of  the  heap  array,  including  the  check  for 
overflow  prior  to  every  insertion,  did  not  prevent  the  heapsort-based  implementation  from 
running  faster  than  the  others  tested  (see  the  results  of  the  Test  1  benchmark). 

The  process  scheduling  primitives  in  MOOSE,  including  process  waiting  and  interrupts, 
together  with  the  fact  that  MOOSE  processes  are  directly  accessible,  have  been  shown  to  be 
sufficient  for  the  implementation  of  many  diverse  simulation  constructs,  including  resources 
and  triggers. 

ERIC 

ERIC  is  an  object-oriented  simulation  tool  designed  and  developed  at  Rome  Labs  [Hilton 
1990],  Initially,  ERIC  stood  for  Enhanced  ROSS  in  Common  LISP,  but  as  ERIC  was 
developed,  it  diverged  from  ROSS  (a  simulation  tool  from  RAND  Corporation)  and  the  name 
is  no  longer  considered  ar.  acronym.  Compared  to  the  other  tools  that  we  considered,  ERIC  is 
unique  in  that  it  is  event-driven.  We  completed  our  first  four  benchmarks  for  ERIC,  but  the 
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fifth  benchmark  and  the  bank  simulation  require  a  notion  of  interrupt.  We  could  find  no  simple 
way  to  model  interrupts  in  ERIC,  due  to  its  event-driven  nature,  and  hence  we  did  not  complete 
the  last  two  benchmarks  for  this  system.  For  our  tests,  we  used  a  version  of  ERIC  in  Allegro 
Common  Lisp  with  the  Common  Lisp  Object  System  (CLOS). 
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SECTION  4 


BENCHMARKS 


The  design  of  performance  benchmarks  for  object-oriented  systems  seems  to  be  an  uncharted 
area.  For  simulation  systems,  Doyle  [Doyle  90]  studied  several  tools  using  a  single 
benchmark.  We  have  chosen  five  feature-specific  benchmarks,  and  a  single  general  purpose 
benchmark.  The  benchmarks  were  implemented  and  timed  in  each  of  the  tested  tools. 


SINGLE  FEATURE  BENCHMARKS 

These  are  small  benchmarks  designed  to  test  single  features  of  the  simulation  tool.  Each  is 
parameterized  by  a  single  integer  input  usually  representing  the  number  of  threads  generated 
(test  5  is  the  exception;  the  integer  parameter  in  that  test  represents  the  number  of  interrupts 
generated).  The  results  are  graphed  and  discussed  in  the  next  section.  Abstractly,  a  thread  is  a 
sequence  of  causally  related  events  operating  on  the  same  state  information.  Exactly  how  a 
“thread”  is  implemented  is  different  for  the  different  simulation  tools.  In  the  transaction-based 
simulation  models,  a  thread  corresponds  to  a  transaction.  In  the  process-based  simulation 
models,  a  thread  corresponds  to  a  process.  Within  a  thread,  at  most  one  event  can  occur  at  any 
simulation  time. 

Test  1  -  Sorting  Threads 

Initially,  N  threads  are  created.  Each  thread  is  given  a  starting  simulation  time  chosen  from  a 
uniformly  distributed  random  variable.  The  threads  simply  terminate  as  soon  as  they  are 
started.  The  system  must  sort  and  execute  the  threads.  Asymptotic  performance  on  this  test 
ranges  from  nearly  linear  for  MOOSE  to  quadratic  on  some  of  the  commercial  tools.  Also,  for 
Sim++  and  ERIC,  two  tests  were  performed  to  illustrate  the  difference  in  performance  when 
each  thread  is  associated  with  a  different  object  and  when  all  threads  are  associated  with  the 
same  object.  In  both  Sim++  and  ERIC,  the  event  list  sorting  algorithm's  asymptotic 
performance  is  better  for  the  case  when  each  thread  is  associated  with  a  different  object 

This  thread  sorting  test  is  expected  to  predict  the  relative  performance  of  the  simulation  tools  on 
simulations  containing  a  large  number  of  threads.  Had  all  of  the  tools  used  similar  sorting 
procedures,  the  test  would  not  be  an  accurate  predictor.  However,  because  of  the  quadratic 
behavior  of  some  of  the  sorting  algorithms,  the  simulation  systems  with  nearly  linear  behavior 
(actually,  0[NlogN]  complexity)  are  clearly  favored  for  large  simulations  over  those  with 
quadratic  behavior. 
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Test  2  -  Thread  Creation 


This  test  is  designed  to  compare  the  overhead  involved  in  creating  and  manipulating  individual 
threads  (all  for  the  same  simulation  object)  without  the  overhead  associated  with  thread  sorting 
measured  in  test  1.  For  this  test,  a  single  thread  is  initially  created  which  spawns  a  child  thread 
and  then  terminates.  The  child  thread  then  spawns  a  third  generation  thread  and  terminates, 
and  so  on  until  N  threads  have  been  generated.  At  any  time,  there  is  at  most  one  thread  waiting 
to  execute,  so  the  overhead  of  sorting  is  not  incurred. 

Differences  between  the  semantics  of  threads  in  the  tools  compared  should  be  noted  when 
examining  the  results  of  this  test.  Those  simulation  tools  that  have  process  semantics  for 
threads  (Smalltalk,  MOOSE,  MODSIM II)  are  trading  overhead  as  measured  in  this  test  for 
power  within  a  process,  which  in  most  cases  would  translate  to  fewer  thread  creations  in  these 
tools  for  given  simulation  than  for  the  non-process  oriented  tools  ( Sim++  and 
SES /workbench).  MODSIM  II  is  actually  somewhat  of  a  hybrid  between  the  process  and  non¬ 
process  models,  since  threads  in  MODSIM  II  can  only  elapse  simulation  time  from  within  their 
outermost  stack  frame. 

Test  3  -  Synchronous  Thread  Creation 

Modularity  issues  arise  in  simulation  languages  just  as  they  do  in  standard  programming 
languages.  The  software  engineering  ideal  for  modularity  is  that  there  should  be  a  negligible 
tradeoff  of  performance  for  modularity  inherent  in  the  language.  This,  however,  is  difficult  to 
test,  since  the  notion  of  modularity  is  not  nearly  as  formalizable  and  measurable  as  is 
performance.  This  test  is  an  attempt  to  show  that  the  implementation  of  some  simulation 
systems  encourages  a  “demodularization”  of  code  exceeding  that  normally  experienced  in 
standard  programming  languages. 

In  standard  programming  languages,  the  most  common  unit  of  modularization  is  the  function 
(procedures  and  methods  are  here  considered  synonymous  with  functions).  Small,  easy  to 
understand  functions  that  encapsulate  simple  ideas  are  preferred  for  modularity,  readability, 
maintainability,  and  nearly  every  other  software  engineering  concern.  It  is  generally  accepted 
that  code  which  localizes  concepts  is  to  be  preferred.  The  largest  drawback  of  function 
modularity  is  the  added  overhead  of  the  extra  function  calls,  but  this  is  not  a  severe 
performance  penalty  in  most  programming  languages.  For  one  of  the  simulation  systems 
investigated  here,  however,  function  modularity  within  threads  can  impact  performance 
considerably.  The  problem  occurs  in  MODSIM  II,  when  a  single  thread  must  pass  through 
several  functions,  any  of  which  may  or  may  not  elapse  simulation  time.  In  all  other  tools,  any 
function  (or  function  equivalent,  such  as  a  subgraph  in  SES/workbench  or  method  in 
MODSIM  II  or  MOOSE)  may  elapse  simulation  time  within  a  thread.  It  is  possible  to  spawn  a 
new  thread  that  is  synchronously  tied  to  its  parent  (the  parent  will  sleep  until  the  child  is  done, 
then  the  parent  will  continue),  but  this  is  not  necessary.  In  MODSIM  II,  however,  it  is 
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necessary  to  spawn  a  synchronous  child  thread  using  the  WAIT  FOR  construct  to  permit  the 
called  method  to  elapse  simulation  time.  This  benchmark  is  designed  to  demonstrate  the  impact 
on  performance  that  this  restriction  can  have.1 

In  test  3,  a  simulation  thread  synchronously  calls  a  child  function.  This  behavior  is  continued 
to  a  depth  equal  to  the  input  parameter.  In  test  3a,  the  function  calls  do  not  elapse  simulation 
time.  In  test  3b,  each  call  elapses  one  unit  of  simulation  time.  In  both  cases,  we  have  coded 
the  test  in  a  manner  that  would  not  prohibit  the  child  from  elapsing  simulation  time  (which 
means  that  a  WAIT  FOR  construct  is  used  in  MODSIM II,  while  direct  function  calls  are  used 
in  all  other  tools). 

Test  4  -  Resource  Queues 

Resources  are  one  of  the  most  common  constructs  found  in  simulation  systems.  Resources  are 
generally  represented  as  queues  with  some  standard  queuing  discipline  (usually  FIFO)  and 
some  number  of  tokens.  Threads  can  request  some  of  the  tokens  from  a  resource.  If  the 
resource  has  sufficient  tokens  to  fulfill  the  request,  the  thread  is  allowed  to  continue.  If  the 
resource  has  too  few  tokens  to  fulfill  the  request,  then  the  requesting  thread  is  queued  and  its 
execution  is  blocked.  Threads  then  can  release  tokens  back  to  resources,  which  may  cause  the 
resources  to  dequeue  waiting  threads  and  allow  them  to  continue  executing. 

Of  the  simulation  systems  tested,  all  but  Sim++  and  ERIC  contain  some  built  in  resource 
construct  with  semantics  equivalent  to  that  described  above.  For  both  Sim++  and  ERIC, 
resources  are  implemented  as  separate  simulation  objects  that  use  event  rescheduling  to  achieve 
the  desired  queuing  and  waiting  semantics. 

For  this  resource  test,  a  resource  containing  single  token  is  created,  and  N  threads  request  the 
resource.  Care  has  been  taken  to  construct  this  test  so  that  at  most  one  thread  at  any  time  is 
scheduled  by  thread  sorting  (as  tested  in  test  1),  so  that  the  overhead  of  the  sorting  algorithm  is 
not  felt  Performance  was  generally  linear  here,  except  for  MODSIM  n,  which  exhibited 
quadratic  performance.  We  have  since  sent  CACI  our  code  for  this  test.  They  profiled  it  to 
find  the  performance  problem  areas  and  report  that  Release  1.6  of  MODSIM  will  include 
improvements. 

Test  5  -  Interrupts 

Interrupts,  like  resources,  are  common  to  most  simulation  systems.  Interrupts  present  a 
semantics  for  the  control  of  threads  by  other  threads.  The  target  thread  of  an  interrupt  is 
always  in  a  wait  state,  since  this  the  only  way  that  the  source  thread  can  have  time  to  initiate  the 
interrupt.  The  source  thread  of  the  interrupt  can  interrupt  the  target  using  some  construct  that 
requires  a  way  of  denoting  the  target  thread  (in  MODSIM  n,  where  threads  are  not 


1  Subsequent  to  our  work,  CACI  has  apparently  corrected  this  problem  in  Release  1.7  with  the 
introduction  of  WAIT  FOR  methods.  When  WAIT  FOR  methods  are  invoked  by  a  WAIT 
FOR  construct,  no  context  switch  occurs. 
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independently  namable  entities,  a  thread  is  denoted  by  the  host  object  and  the  method  name  - 
this  technique  may  not  always  indicate  a  unique  thread).  The  target  thread  of  the  interrupt  is 
scheduled  to  execute  immediately  after  the  interrupt  (or,  at  least  before  any  simulation  time 
elapses),  and  control  within  the  thread  is  usually  transferred  to  some  interrupt  handler. 

Of  the  simulation  systems  tested,  all  but  Sim++,  Smalltalk,  and  ERIC  contain  a  built  in 
interrupt  facility.  For  Smalltalk,  an  interrupt  mechanism  was  added  simply  by  adding  the 
appropriate  methods  to  some  of  the  built  in  simulation  classes.  For  Sim++  and  ERIC,  an  event 
rescheduling  feature  was  used  to  obtain  the  interrupt  semantics. 

For  this  test,  a  source  thread  and  a  target  thread  are  created.  The  source  thread  will  interrupt 
the  target  thread  N  times,  each  time  while  the  target  thread  is  waiting  within  a  delay  construct. 
The  interrupt  handler  for  the  target  thread  simply  re-invokes  the  delay,  causing  the  target  thread 
to  wait  for  the  next  interrupt.  For  this  test,  all  tools  showed  similar  performance. 

BANK  SIMULATION  BENCHMARK 

The  bank  simulation  is  our  revision  and  enlargement  of  an  example  supplied  with  MODSIM II. 
The  purpose  of  this  benchmark  is  to  test  many  simulation  system  features  together  within  the 
context  of  a  “typical”  simulation.  The  simulation  consists  of  “customers”  and  “VIPs”  that  enter 
a  simulation  of  a  bank,  requiring  service.  There  are  a  fixed  number  of  identical  servers 
("tellers")  in  the  system.  When  a  customer  enters  the  simulation,  it  selects  a  server  with  the 
shortest  queue.  When  a  VIP  enters,  it  selects  a  server  at  random  and  attempts  to  receive 
immediate  service.  If  the  teller  chosen  by  a  VIP  is  serving  a  non- VIP  customer,  the  customer 
is  interrupted  and  the  VIP  is  served;  if  the  server  is  serving  another  VIP,  the  requesting  VIP 
simply  departs  the  system  in  disgust.  The  servicing  of  a  customer  interrupted  by  a  VIP  is 
resumed  after  the  VIP  has  been  serviced. 
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Figure  1.  Bank  Simulation  Sketch 


To  make  the  simulation  a  bit  more  interesting,  while  a  customer  is  in  a  queue,  it  may  “time-out” 
and  be  required  to  visit  the  lavatory.  A  lavatory  has  a  number  of  stalls.  Customers  visit  the 
lavatory  appropriate  to  their  gender  and  use  the  first  available  open  stall.  After  the  lavatory  visit 
is  complete,  the  customer  again  selects  a  teller  with  the  shortest  queue.  Furthermore,  every 
customer  has  a  “lavatory  line  length  tolerance”  -  if  the  line  to  the  lavatory  exceeds  this 
tolerance,  the  customer  will  leave  the  bank  and  seek  "alternate  facilities,"  rather  than  wait  on 
line.  The  bank  thus  has  an  implicit  saturation  point,  past  which  a  higher  rate  of  arrival  of 
customers  will  result  only  in  the  excess  customers  leaving  the  bank.  However,  the  complex 
interaction  of  customers,  VIPs,  and  visits  to  the  lavatory  makes  any  analytic  determination  of 
the  saturation  point  non-trivial 

The  generic  benchmark  was  coded  and  successfully  run  on  all  systems  except  MODSIM II. 
Under  Release  1.5  of  MODSIM  n,  we  experienced  run-time  errors  related  to  the  interrupt 
constructs.  We  reported  the  error  and  received  a  beta  version  of  Release  1.6  under  which  the 
simulation  runs  correctly. 
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SECTION  5 
TIMING  RESULTS 


TEST  1 

The  timing  results  for  Test  1  are  shown  in  figure  2  below.  Since  the  benchmark  tests  the 
sotting  algorithm  implemented  by  the  run-time  environment  of  the  simulation  tools,  asymptotic 
behavior  of  0(n  log  n)  was  expected.  Surprisingly,  most  of  the  tools  exhibited  quadratic 
behavior.  The  exceptions  are  MOOSE  and  Sim++  (when  the  threads  are  scheduled  for  distinct 
entities).  Not  as  surprisingly,  Smalltalk  performed  significantly  worse  than  any  of  the  other 
tools. 

Note  that  the  "N  queues"  result  for  Sim++  was  measured  as  the  difference  between  two 
separate  tests  so  that  the  overhead  of  creating  entities  could  be  removed.  The  cost  of  creating 
entities  was  significantly  more  than  the  cost  of  creating  threads. 

The  inability  to  run  the  SES/workbench  benchmark  for  more  then  6,000  iterations  is 
unexplained.  Our  implementation  simply  never  terminated  at  this  input  level.  The  lack  of  data 
past  7,000  iterations  of  the  Sim++  (N  queues)  implementation  reflects  the  point  at  which  the 
physical  memory  of  the  workstation  used  was  exhausted.  After  that  point  the  effects  of  paging 
could  not  be  separated  and  the  data  was  discarded. 

The  authors  speculate  that  the  tools  are  optimized  for  simulations  where  the  number  of  events 
on  the  queue  is  not  large  and,  therefore,  the  constant  multiplier  may  be  a  greater  consideration 
than  the  order  of  the  sorting  algorithm  used.  Also,  we  do  not  know  if  using  uniformly 
distributed  event  times  is  a  suitable  approximation  to  the  function  of  typical  simulations,  where 
event  times  may  appear  in  an  almost  sorted  order. 

TEST  2 

Figures  3  and  4  show  the  results  of  this  benchmark.  Once  again  Smalltalk  took  much  more 
time  to  perform  the  same  number  of  iterations  as  any  of  the  other  tools.  In  fact,  the  Smalltalk 
results  are  removed  from  figure  4  so  that  the  relative  differences  of  the  other  tools  could  be 
shown  clearly.  As  expected,  the  cost  of  creating  a  thread  is  roughly  linear  in  the  number  of 
threads  created. 
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Figure  2.  Test  1  Performance 


28 


s«cond* 


29 


Second* 


Figure  4.  Test  2  Performance  (no  Smalltalk-80  or  ERIC) 
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TEST  3 


The  results  of  benchmarks  3a  and  3b  are  shown  in  figures  5  and  6,  respectively. 

MODSIM II  is  the  only  tool  where  a  module  must  be  both  coded  and  called  in  a  particular 
fashion,  as  a  TELL  method,  if  it  might  elapse  simulation  time.  As  the  results  of  Test  3a  show, 
there  is  a  substantial  performance  penalty  for  calling  a  TELL  method,  using  the  WATT  FOR 
construct,  even  when  the  method  does  not  elapse  simulation  time.  The  shape  of  the  curve 
suggests  that  the  quadratic  sorting  algorithm  is  invoked,  as  expected  from  Test  1. 

Not  surprisingly,  the  performance  was  best  in  the  C-H-based  tools  MOOSE  and  Sim++\  the 
overhead  introduced  is  that  of  a  method  invocation.  Similarly,  the  Smalltalk  implementation 
introduced  a  method  invocation  overhead  which,  while  substantially  more  than  that  of  the  C++- 
based  tools,  was  modest.  The  SES/workbench  technique  of  invoking  a  subgraph  was 
substantially  slower  than  even  the  Smalltalk  method  invocation. 

For  all  of  the  tools,  the  difference  between  Test  3a  and  Test  3b  should  have  been  measured  by 
Test  2.  This  seems  to  be  the  case  for  all  but  Smalltalk,  a  result  that  is  unexplained. 

TEST  4 

The  results  of  this  benchmark  are  shown  in  Figures  7  and  8.  The  results  of  the  Smalltalk  and 
MODSIM  II  runs  have  been  omitted  from  figure  8  in  order  to  better  show  the  data  for  the 
others. 

The  overhead  of  acquiring  a  resource  should  be  low.  The  implementation  of  a  resource  in  the 
Sim++  code  shows  the  relatively  simple  operations  needed  and  that  a  user  can  easily  implement 
resources  with  a  cost  that  is  a  small  multiple  of  the  cost  of  creating  a  thread.  The  nonlinear 
results  of  MODSIM  II  and  Smalltalk  are  unexplained. 

TEST  5 

Figure  9  shows  the  results  of  this  benchmark.  Interrupts  should  incur  an  overhead  equal  to  a 
small  multiple  of  the  cost  of  creating  a  thread.  This  expectation  seems  to  be  met  by  each  of  the 
tools. 
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Figure  5.  Test  3a  Performance 
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Figure  7.  Test  4  Performance 
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Figure  8.  Test  4  Performance  (Smalltalk-80,  MODSIM  n,  and  ERIC  are  omitted) 
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BANK  SIMULATION  BENCHMARK 

The  results  of  the  bank  simulation  benchmark  are  shown  in  figure  10.  Two  versions  of  this 
test  were  performed:  one  where  the  customer  arrival  rate  closely  matches  the  service  times, 
yielding  a  system  operating  at  its  saturation  point;  in  the  second,  the  customer  arrival  rate 
exceeds  the  service  capacity  considerably,  yielding  a  system  operation  well  above  its  saturation 
point.  The  operation  of  the  bank  simulation  is  such  that  the  queues  never  grow  too  long 
(customers  leave  to  go  to  the  restrooms,  and  leave  the  simulation  entirely  if  the  restroom  lines 
are  too  long),  so  the  difference  in  performance  between  the  two  versions  of  the  test  for  each 
tool  is  not  likely  to  be  due  to  the  queueing  algorithms.  Instead,  the  difference  reflects  the  fact 
that  each  tool  spends  more  of  its  time  creating  customer  objects  (threads)  in  the  over  saturated 
version  than  in  the  saturated  version.  For  all  tools  except  Sim++,  thread  creation  is  more 
expensive  than  other  processing. 

The  overall  results  of  the  bank  simulation  test  show  that  the  relative  performance  of  the  tools  on 
realistic  simulation  problems  is  predicted  rather  well  by  their  relative  performance  on  the  single 
feature  benchmarks. 


lover  saturated  11  saturated 

Figure  10.  Bank  simulation  Performance 
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SECTION  6 


SUMMARY  AND  CONCLUDING  REMARKS 


Our  survey  found  a  wide  variety  of  features  and  performance  in  object-oriented  simulation 
tools.  On  the  performance  side,  Smalltalk  represents  one  extreme,  paying  major  penalties  for 
making  decisions  at  run  time.  At  the  other  extreme  is  our  hand-coded  MOOSE,  which  excels  at 
most  of  the  benchmarks.  Our  benchmarking  effort  has  generally  reinforced  the  rule  of  thumb 
that  Smalltalk  code  runs  about  one  order  of  magnitude  slower  than  comparable  optimized  C 
code.  For  the  other  systems  that  compile  into  C,  we  found  SES/workbench  to  be  surprisingly 
efficient,  while  MODSIM II  and,  to  a  lesser  extent,  Sim++  were  not  as  efficient 

It  is  important  to  emphasize  that  performance  is  only  one  facet  of  the  evaluation  of  a  simulation 
tool.  In  some  contexts,  the  time  and  effort  required  to  create  the  simulation  code  may  be  more 
critical  than  the  code’s  execution  time.  While  we  are  confident  that  our  benchmarking  effort 
provides  clear  performance  distinctions,  we  feel  less  confident  drawing  conclusions  concerning 
the  time  it  takes  to  develop  a  simulation  in  a  particular  tool,  or  the  time  required  to  maintain  or 
upgrade  an  existing  simulation.  These  issues  tend  to  depend  on  complex  human  factors. 

Some  individuals  my  find  the  graphical  interface  of  SES/workbench  to  be  a  large  advantage, 
while  others  may  feel  that  it  is  a  hindrance  in  that  it  restricts  access  to  the  simulation  code.  The 
Smalltalk-80  language  and  programming  environment  provide  a  powerful  collection  of  tools, 
but  novice  users  will  certainly  be  very  bewildered  during  initial  attempts  to  assimilate  the 
system. 

To  consider  the  issue  of  programming  languages  in  general,  it  is  clear  that  C++  currently  has  a 
number  of  advantages:  it  is  enjoying  widespread  popularity,  with  high  quality  and  either  public 
domain  or  low  cost  implementations  available  for  an  assortment  of  hardware  platforms. 
Libraries  of  reusable  classes  for  C++  are  growing  in  number,  and  support  for  simulation  is 
available  from  several  sources.  Environments  that  support  C++  program  development  are 
becoming  more  widely  used.  The  language  has  significant  momentum  and  this  is  an  important 
consideration  when  choosing  a  programming  language. 

The  three  commercial  simulation  tools  are  similar  in  their  high  licensing  costs  and  their  promise 
to  provide  users  with  support.  In  most  other  areas,  these  commercial  tools  are  quite  different. 
Let  us  start  with  MODSIM  II.  This  tool  has  made  a  substantial  amount  of  progress  since  its 
introduction.  New  features,  such  as  compilation  of  circular  references  and  WAIT  FOR 
methods,  have  been  introduced  as  users  have  identified  problems.  In  addition,  CACI  has 
received  preliminary  benchmark  information  from  us,  and  they  have  worked  on  the  latest 
release  of  their  system  to  improve  their  performance  numbers.  The  basic  simulation  style  of 
MODSIM  II  seems  to  be  successful;  we  chose  to  exchange  definitions  of  the  bank  simulation 
problem  in  MODSIM  II  code.  The  graphics  support  provided  by  CACI  is  certainly  a  positive 
feature.  On  the  negative  side,  we  have  seen  that  the  performance  of  MODSIM  n  is 
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disappointing.  In  terms  of  features,  there  are  still  a  few  things  missing,  for  instance, 
overloading  of  method  names.  The  decision  to  separate  methods  into  ASK  and  TELL  variants, 
and  the  subsequent  addition  of  WAIT  FOR  methods,  may  not  be  the  best  path;  a  single  type  of 
method  was  adopted  for  MOOSE. 

SES/workbench  was  included  in  this  study  since  it  is  a  tool  currently  available  at  MITRE  and  it 
makes  some  claims  towards  being  object-oriented.  In  truth,  the  typical  user  interaction  with 
this  tool  will  involve  none  of  the  features  of  object-oriented  programming.  The  support  for 
object-oriented  programming  in  the  programming  language  SES/sim  does  not  extend  into  the 
graphical  interface.  The  clear  focus  in  this  product  is  extended  queueing  networks,  and  this  is 
an  important  and  very  useful  paradigm.  SES  has  informed  us  that  they  are  interested  in 
working  on  a  new  tool  that  would  be  more  object-oriented,  but  no  details  have  been 
established.  The  performance  of  SES /workbench  was  impressive,  especially  given  that  the 
code  was  generated  from  graphic  input 

Sim++  is  a  system  specifically  focused  on  parallel  execution  of  simulations  as  a  means  of 
greatly  improving  performance.  Our  tests  used  only  sequential  Sim++,  partly  because  the 
parallel  version  was  not  available  to  us,  and  partly  because  performance  evaluation  of  parallel 
processing  is  outside  the  scope  of  what  we  could  accomplish  in  this  evaluation  task.  From  the 
coding  of  the  bank  simulation,  it  seems  fair  to  say  that  Sim++  was  the  most  difficult  of  our  five 
primary  systems  to  develop  code  in.  This  is  due  to  that  fact  that  the  design  methodology 
enforces  an  approach  that  facilitates  parallel  execution,  but  puts  somewhat  of  an  extra  burden 
on  the  programmer.  The  performance  of  Sim++  on  the  bank  simulation  was  fairly  good;  it 
appears  that  the  performance  penalty  created  by  the  focus  on  parallel  execution  is  less  than  the 
design  penalty.  Clearly,  the  utility  of  Sim++  must  be  based  on  how  successful  it  is  at 
generating  speed  up  when  running  in  parallel.  This  would  be  an  interesting  topic  for  another 
performance  study. 

To  conclude,  as  we  began  this  project,  we  found  little  existing  work  in  performance  analysis 
for  object-oriented  systems.  Our  efforts  have  provided  a  start  in  this  area.  For  simulation 
tools,  we  developed  a  small  set  of  feature  benchmarks.  These  benchmarks  are  certainly  not 
exhaustive,  and  more  work  is  necessary  to  assemble  a  complete  approach  to  such  benchmarks. 
Our  single  larger  benchmark  was  of  a  rather  simple  system.  It  would  be  interesting  to  look  at  a 
more  complex  simulation.  We  believe  it  likely  the  performance  characteristics  of  the  tools 
would  remain  the  same  in  a  larger  benchmark.  One  of  the  advantages  of  doing  a  larger 
benchmark  would  be  to  get  more  information  on  program  development  time. 
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APPENDIX  A 


MODSIM  II  CODE 


MAIN  MODULE  Testl; 

FROM  UtilMod  IMPORT  GetCmdLineArg; 

FROM  SimMod  IMPORT  StartSlmulation,  SimTime; 

FROM  RanOtod  IMPORT  RandomObj; 

TYPE 

Foo  -  OBJECT 

TELL  METHOD  Bar  ()  ; 

END  OBJECT; 

OBJECT  Foo; 

TELL  METHOD  Bar  () ; 

BEGIN 

END  METHOD; 

END  OBJECT; 

VAR 

f  :  Foo; 

1,  j  :  INTEGER; 
a  :  STRING; 
r  :  RandomObj; 

BEGIN 

NEW  (I)  ; 

NEW(r); 

GetCmdLineArg (1,  s) ; 

1  STRTOINT (a) ; 

FOR  J  1  TO  1 

TELL  f  TO  Bar()  IN  ASK  r  UniformReal (0.0, 

1000.0); 

END  FOR; 

StartSlmulation  (); 

END  MODULE. 


MAIN  MODULE  Test3a; 

FROM  UtilMod  IMPORT  GetCmdLineArg; 

FRCM  SimMod  IMPORT  StartSlmulation,  SimTime; 
FROM  RandMod  IMPORT  RandomObj; 

TYPE 

Foo  -  OBJECT 

TELL  METHOD  Bar  (IN  n  :  INTEGER) ; 
END  OBJECT; 

VAR 

f  :  Foo; 
i,  j  :  INTEGER; 
a  :  STRING; 
r  :  RandomObj; 

C3JECT  Foo; 

TELL  METHOD  Bar  (IN  n  ;  INTEGER); 

BEGIN 

n  n  -  1; 

IF  n  >  0 

WAIT  FOR  f  TO  Bar (n) 

END  WAIT; 

END  IF; 

END  METHOD; 

END  OBJECT; 

BEGIN 

NEW(f); 

NEW (r) ; 

GetCmdLineArg (1 ,  s) ; 
i  STRTOINT (s); 

TELL  f  TO  Bar  (i)  ; 

StartSlmulation  () ; 

END  MODULE. 


MAIN  MODULE  T«st2; 


FROM  UtilMod  IMPORT  GetCmdLinaArg; 

FROM  SimMod  IMPORT  StartSlmulation,  SimTime, 
FROM  RandMod  IMPORT  RandonObj; 

TYPE 

Foo  -  OBJECT 

TELL  METHOD  Bar  (IN  n  :  INTEGER), 
END  OBJECT; 

VAR 

f  :  Foo; 
i,  J  ;  INTEGER; 
s  :  STRING; 
r  :  RandomObj  ; 

OBJECT  Foo; 

TELL  METHOD  Bar  (IN  n  :  INTEGER)  ; 

BEGIN 

n  n  -  1; 

IF  n  >  0 

TELL  f  TO  Bar  (n) ; 

END  IF; 

END  METHOD; 

END  OBJECT; 

BEGIN 

NEW ( f ) ; 

NEW (r) ; 

GetCmdLineArg (1,  s) ; 
i  STRTOINT (a); 

TELL  f  TO  Bar  (1)  ; 

StartSlmulation  () ; 

END  MODULE. 


MAIN  MODULE  Test3b; 

FR0M  UtilMod  IMPORT  GetCmdLineArg; 

FROM  SimMod  IMPORT  StartSlmulation,  SimTime; 
FROM  RancMod  IMPORT  RandomObj; 

TYPE 

Foo  -  OBJECT 

TELL  METHOD  Bar  (IN  n  ;  INTEGER); 
END  OBJECT; 

VAR 

f  :  Foo; 
i,  j  :  INTEGER; 
a  ;  STRING; 
r  :  RandomObj; 

OBJECT  Foo; 

TELL  METHOD  Bar  (IN  n  :  INTEGER); 

BEGIN 

WAIT  DURATION  1.0  END  WAIT; 
n  n  -  1; 

IF  n  >  0 

WAIT  FOR  f  TO  Bar  (n) 

END  WAIT; 

END  IF; 

END  METHOD; 

END  OBJECT; 

BEGIN 

NEW(f) ; 

NEW(r) ; 

GetCmdLineArg (1,  a); 
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i  sTRTOitrr  (*) ; 

TELL  f  TO  Bar(l); 
StartSimulation  <)  ; 
END  MODULE. 


MAIN  MODULE  Test4; 

FROM  UtllMod  IMPORT  GetCmdLlneArg; 

FROM  ResMod  IMPORT  ResourceObj; 

FROM  SlraMod  IMPORT  StartSimulation,  SlmTlme; 

TYPE 

CustomerObj  -  OBJECT 

TELL  METHOD  Run  (IN  n  :  INTEGER); 

END  OBJECT; 

VAR 

Cust  :  CustomerObj; 

Res  :  ResourceObj; 

I  :  INTEGER; 

Str  :  STRING; 

OBJECT  CustomerObj; 

TELL  METHOD  Run (IN  n  :  INTEGER); 

BEGIN 

IF  n  >  1 

TELL  SELF  TO  Run(n  -  1)  IN  1.0; 

END  IF; 

WAIT  FOR  Res  TO  Give(SELF,  1) ; 

END  WAIT; 

WAIT  DURATION  1000000.0 
END  WAIT* 

ASK  Res  TO  TakeBack (SELF , 1 ) ; 

END  MET HOD ; 

END  OBJECT; 

BEGIN 

NEW  (Cust); 

NEW (Res); 

ASK  Res  TO  Created); 

GetQndLi neArg  ( 1 ,  Str); 

I  STRTOINT  (Str)  ; 

TELL  Cust  TO  Run (I); 

StartSimulation; 

END  MODULE. 


MAIN  MODULE  Test 5; 

FROM  UtllMod  IMPORT  GetCmdLlneArg; 

FROM  SlraMod  IMPORT  StartSimulation,  SlmTlme, 
Interrupt; 

TYPE 

FOO  -  OBJECT 

TELL  METHOD  LongDelayLoop  (IN  I :  INTEGER)  ; 
TELL  METHOD  InterruptLoop  (IN  J:  INTEGER)  ; 
END  OBJECT; 

OBJECT  Foo; 

TELL  METHOD  LongDelayLoop  (IN  I :  INTEGER) ; 

BEGIN 

(OUTPUT ("LongDelayLoop  started");) 

WAIT  DURATION  100.0 
ON  INTERRUPT 

(OUTPUT ("LongDelay  Interrupted");! 

IF  I  >  0  TELL  SELF  TO  LongDelayLoop (I  -  1); 

END  IF; 

END  WAIT; 

(OUTPUT ("LongDelayLoop  finished*);) 

END  METHOD; 

TELL  METHOD  InterruptLoop  (IN  J:  INTEGER); 

BEGIN 

(OUTPUT ("Interrupter  started");! 


WAIT  DURATION  1.0 
END  WAIT; 

IF  J  >  0  Interrupt (SELF,  "LongDelayLoop"); 

TELL  SELF  TO  InterruptLoop (J  -  1); 
END  IF; 

(OUTPUT (“Interrupter  finished") ;| 

END  METHOD; 

END  OBJECT; 

VAR 

f  :  Foo; 

Num  :  INTEGER; 

Str  :  STRING; 

BEGIN 

NEW(f) ; 

GetCmdLlneArg (1,  Str); 

Num  STRTOINT (Str); 

TELL  f  TO  LongDelayLoop(Num) ; 

TELL  f  TO  InterruptLoop(Num) ; 
StartSimulation  () ; 

END  MODULE. 


MAIN  MODULE  Sim; 

FROM  SimMod  IMPORT  StartSimulation,  SlmTlme, 
Interrupt,  TrlggerObj; 

FROM  ResMod  IMPORT  ResourceObj; 

FROM  RandMod  IMPORT  RandomObj; 

FRCM  MathMod  IMPORT  LN; 

FROM  UtllMod  IMPORT  ClockTimeSecs; 

TYPE 

Gender  -  (Female,  Male); 

CustomerObj  -  OBJECT;  FORWARD; 

VIPObj  -  OBJJCT;  FORWARD; 

LlneObj  -  OBJECT (ResourceObj) 
serving  :  CustomerObj; 
canContinue  :  TrlggerObj; 

TELL  METHOD  ServeCust  (IN  cust  : 
CustomerObj) ; 

OVFRRTDF 

ASK  METHOD  Objlnlt  0; 

END  OBJECT; 

RestRoom  -  ResourceObj; 

CustomerObj  -  OBJECT 

myGender  :  Gender; 

ASK  METHOD  Objlnlt  0 ; 

TELL  METHOD  GetOnLine  (); 

TELL  METHOD  VlsltFacilltles  0; 
PRIVATE 

ASK  METHOD  FindBestLlne  ()  :  LlneObj 
END  OBJECT; 

EndSlm  -  OBJECT 

TELL  METHOD  Stop  () ; 

END  OBJECT; 

VIPObj  -  OBJECT (CustomerObj) 

OVERRIDE 

TELL  METHOD  GetOnLine  (); 

END  OBJECT; 

CustGeneratorObj  -  OBJECT 

TELL  METHOD  GenCustomers  (); 

END  OBJECT; 
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Erlang (meanLineTolerance, 


VIPGeneratorObj  -  OBJECT (CustGeneratorObj) 
OVERRIDE 

TELL  METHOD  GenCustomers  (); 

END  OBJECT; 

MoreRandomObj  -  OBJECT (RandomObj) 

{  add  the  Erlang  distribution  ) 

ASK  METHOD  Erlang  (IN  mean,  variance  : 
REAL)  :  REAL; 

END  OBJECT; 


VAR 

hoursToRun, 

meanlnterArrlveTlme, 

meanVIPInterArrlveTime, 

meanNatureCallsTlme, 

varianceNatureCallsTime, 

meanLlneTolerance, 

variance Li neTolerance, 

meanServiceTime, 

varianceServiceTlme  ;  REAL; 

k  :  INTEGER; 

numLlnes  :  INTEGER; 

line  :  LlneObj; 

allLlnes  :  ARRAY  INTEGER  OF  LlneObj; 
random  :  MoreRandomObj; 
restRooms  ;  ARRAY  Gender  OF  RestRoom; 
rest RoomMeanT ime , 

restRoomVarTime  :  ARRAY  Gender  OF  REAL; 
custGenerator  ;  CustGeneratorObj; 
vipGenerator  :  VIPGeneratorobj; 
seed  :  INTEGER; 
endsim  :  EndSim; 


OBJECT  CustomerObj; 

ASK  METHOD  Objlnit  ()  ; 

BEGIN 

myGender  :•  VAL (Gender,  ASK  random 
Unlformlnt (0,  1) ) ; 

TELL  SELF  TO  GetOnLlne; 

END  METHOD; 


TELL  METHOD  GetOnLlne  ()  ; 

VAR 

myLlne  ;  LlneObj; 
tlmeTlllNatureCalls  :  REAL; 
BEGIN 


random 


LOOP 

LOOP 

tlmeTlllNatureCalls 


ASK 


Erlang (meanNatureCallsTlme, 

varlanceNatureCallsTime) ; 

myLlne  ASK  SELF  TO 

FlndBeatLine  0 ; 

WAIT  FOR  myLlne  TO 

TimedGive(SELF,  1,  tlmeTlllNatureCalls) 

EXIT; 

ON  INTERRUPT 

WAIT  FOR  SELF  TO 

VI sit Facilities 

END  WAIT; 

END  WAIT; 

END  LOOP; 

WAIT  FOR  myLlne  TO  ServeCust (SELF) 
END  WAIT; 

ASK  myLlne  TO  TakeBack  (SELF,  1) ; 
EXIT; 

END  LOOP; 

DISPOSE (SELF) ; 

END  METHOD; 

TELL  METHOD  VlsltFacllities  ()  ; 

VAR 

restRoom  :  RestRoom; 
restRoomLlneTolerance  :  INTEGER; 

BEGIN 

restRoom  rest Rooms ( myGender ] ; 

restRoomLlneTolerance  ROUND (ASK  random 


varianceLi neTolerance) ) ; 

IF  ASK  restRoom  TO  ReportNumberPending ()  > 
rest  RoomLi neTolerance 

DISPOSE (SELF) ; 

TERMINATE; 

ELSE 

WAIT  FOR  restRoom  TO  Give (SELF,  1) 

END  WAIT; 

WAIT  DURATION  ASK  random 
Erlang (restRoomMeanTime[myGender) , 

restRoomVarTime [myGender] ) 

£ND  WAIT* 

ASK  restRoom  TO  TakeBack (SELF,  1); 

END  IF; 

END  METHOD; 

ASK  METHOD  FindBestLlne  (>  :  LlneObj; 

VAR 

line,  bestLine  :  LlneObj; 
length,  bestLength,  1  :  INTEGER; 

BEGIN 

bestLength  MAX  (INTEGER)  ; 

FOR  1  1  TO  numLlnes 

line  allLlnes [1]; 
length  ASK  line  TO 
ReportNumberPendingO ; 

IF  ASK  line  TO  ReportAvallability ()  -  0 
length  :»  length  +  1; 

END  IF; 

IF  length  <  bestLength 

bestLength  length; 
bestLine  line; 

END  IF; 

END  FOR; 

RETURN  bestLine; 

END  METHOD; 

END  OBJECT; 

OBJECT  VIPObj; 

TELL  METHOD  GetOnLlne  ()  ; 

VAR 

line  :  LlneObj; 
oldCust  ;  CustomerObj; 

BEGIN 

line  allLlnes [ASK  random  Unlformlnt (1, 

numLlnes) ] ; 

oldCust  :*  ASK  line  serving; 

IF  oldCust  o  NILOBJ 

IF  I SANCESTOR (VIPObj,  oldCust) 

RETURN; 

END  IF; 

Interrupt (line,  "ServeCust") ; 

ELSE 

WAIT  FOR  line  TO  Give (SELF,  1) 

END  WAIT; 

END  IF; 

WAIT  FOR  line  TO  ServeCust  (SELF) 

END  WAIT; 

IF  OldCust  <>  NILOBJ 

WAIT  FOR  line.canContlnue  TO  TriggerO 
END  WAIT; 

ELSE 

ASK  line  TO  TakeBack (SELF,  1); 

END  IF; 

DISPOSE (SELF); 

END  METHOD; 

END  OBJECT; 

OBJECT  MoreRandomObj; 

ASK  METHOD  Erlang  (IN  mean,  variance  :  REAL)  : 

REAL; 

VAR 

k  :  INTEGER; 

1  :  INTEGER; 
prod  ;  REAL; 

BEGIN 

k  ROUND (mean  *  mean  /  variance); 
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IF  k  <-  0 

OUTPUT (“Bad  parameters  to  Erlang. "); 

HALT; 

END  IF; 
prod  1.0; 

FOR  1  :■  1  TO  k 

prod  prod  *  ASK  SELF  UniforaReal (0.0, 

1.0); 

END  FOR; 

RETURN  -LN(prod)  *  mean  /  FLOAT  (k); 

END  METHOD; 

END  OBJECT; 

OBJECT  LineObJ; 

ASK  METHOD  ObJInit  () ; 

BEGIN 

INHERITED  Objlnlt; 

NEW (canContlnue) ; 

END  METHOD; 

TELL  METHOD  ServeCust  (IN  oust  :  CustcmerObj) ; 
VAR 

svcTlme  :  REAL; 
startTlme  :  REAL; 

BEGIN 

svcTlme  :-  ASK  random 

Erlang (meanServiceTlme,  varlanceServiceTime) ; 

LOOP 

startTlme  SlmTlmeO; 
serving  ;•  cust; 

IF  svcTlme  <-  0.0 
EXIT; 

END  IF; 

WAIT  DURATION  svcTlme 
serving  : -  NILOBJ; 

EXIT; 

ON  INTERRUPT 

svcTlme  :■  svcTlme  -  (SlmTlmeO 

-  startTlme) ; 

LOOP 

WAIT  FOR  canContlnue  TO  Fire() 
EXIT; 

ON  INTERRUPT 
END  WAIT; 

END  LOOP; 

END  WAIT; 

END  LOOP; 

END  METHOD; 

END  OBJECT; 

OBJECT  CustGeneratorObj; 

TELL  METHOD  GenCustomers  () ; 

VAR 

customer  :  CustomerObJ; 
waltTlme  :  REAL; 

BEGIN 

LOOP 

waltTlme  ASK  random 
Exponential (meanlnterArrlveTlme) ; 

WAIT  DURATION  waltTlme; 

END  WAIT; 

NEW  (customer)  ; 

END  LOOP; 

END  METHOD;  (  GenCustomers  ) 

END  OBJECT; 

OBJECT  VIPGeneratorObJ; 

TELL  METHOD  GenCustomers  <) ; 

VAR 

vlp  :  VIPOb); 
waltTlme  :  REAL; 

BEGIN 

IF  meanVIPInterArriveTime  >0.0 
LOOP 

waltTlme  ASK  random 
Exponential (meanVIPInterArriveTime) ; 

WAIT  DURATION  waltTlme; 

END  WAIT; 

NEW  (vlp); 

END  LOOP; 

END  IF; 

END  METHOO;  (  GenCustomers  ) 


END  OBJECT; 

OBJECT  EndSlm; 

TELL  METHOD  Stop  ()  ; 

BEGIN 

HALT  ()  ; 

END  METHOD; 

END  OBJECT; 

BEGIN 

(NEW (dt) ; ) 

(TELL  dt  TO  Timeout  ()  IN  1.0;) 

NEW(restRooms,  Female  ..  Male); 

NEW (restRooms (Female) ) ; 

ASK  restRooms(Female)  TO  Create(4); 

NEW (restRooms (Male) ) ; 

ASK  restRooms (Male)  TO  Create(4); 

NEWfrestRoonMeanTlme,  Female  ..  Male); 

NEW(restRoomVarTime,  Female  ..  Male); 

restRoomMeanTlme [Female)  :•  S.0; 

restRoamMeanTime(Male)  :*  3.0; 

restRoamVarTime(Feraale)  8.0; 

restRocmVarTlme(Male)  6.0; 

OUTPUT (“MODSIM  II  Simulation  ’Lines  and  Rest 
Rooms’  starting — “); 

OUTPUT (“What  Is  the  mean  customer  lnterarrlval 
time  In  minutes?”); 

INPUT (meanlnterArrlveTlme) ; 

OUTPUT (“What  is  the  mean  VIP  lnterarrlval  time  In 
minutes?") ; 

INPUT (meanVIPInterArriveTime) ; 

OUTPUT (“What  Is  the  mean  service  time  In 
minutes?”) ; 

INPUT (meanServiceTlme) ; 

OUTPUT ("What  Is  the  variance  of  the  service 
time?”); 

INPUT (varlanceServiceTime) ; 

OUTPUT (“What  Is  the  mean  time  In  minutes  till 
‘Nature  Calls’?”); 

INPUT (meanNat  ureCal IsTime) ; 

OUTPUT (“What  Is  the  variance?”); 

INPUT (varianceNatureCallsTime) ; 

OUTPUT (”What  is  the  mean  restroom  line  length 
tolerance?”) ; 

INPUT (meanLineTolerance) ; 

OUTPUT ("What  Is  the  variance?"); 

INPUT (varianceLineTolerance) ; 

OUTPUT ("How  many  lines  are  there?"); 

INPUT (numLlnes) ; 

OUTPUT ("How  many  hours  should  the  simulation 
run?*) ; 

INPUT (hoursToRun) ; 

OUTPUT (“Random  Seed?"); 

INPUT (seed) ; 

OUTPUT ("Mean  Interarrlve  Time:  ", 
meanlnterArrlveTlme) ; 

OUTPUT ("Mean  VIP  Interarrlve  Time:  ", 
meanVIPInterArriveTime) ; 

OUTPUT ("Mean  Service  Time:  ",  meanServiceTlme); 

OUTPUT  ("Variance  Service  Time:  ", 
varlanceServiceTime) ; 

OUTPUT (“Mean  ’Nature  Calls’  Time:  ", 
meanNat:  ureCal  IsTime) ; 

OUTPUT ("Variance  ’Nature  Calls’  Time:  ", 
varianceNatureCallsTime) ; 

OUTPUT (“Mean  line  length  tolerance:  ", 
meanLineTolerance) ; 

OUTPUT  ("Variance  line  length  tolerance:  ", 
varianceLineTolerance); 

OUTPUT ("Number  of  lines:  “,  numLlnes); 

OUTPUT  ("Hours  to  run:  ",  hoursToRun); 

NEW  (a  1  lLlnes,  1  ..  numLlnes); 

FOR  k  :-  1  TO  numLlnes 
NEW (line) ; 

ASK  line  TO  Created); 
allLines(k)  :-  line; 

END  FOR; 

NEW ( random) ; 

ASK  random  TO  Set Seed (seed) ; 

NEW (custGenerator) ; 

NEW (vlpGenerator) ; 
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NEW  (andaia) ; 

TELL  custGenarator  TO  GanCustomers () ; 
TELL  vipGenarator  TO  GanCustcraers () ; 

TELL  and aim  TO  Stop  IN  60.0  *  hoursToRun; 
Start Simulation; 

END  MODULE. 
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APPENDIX  B 


SES /workbench  CODE 


On  the  following  three  pages,  we  have  reproduces  screen  images  of  the  directed  graphs  that 
represent  the  top  level  of  the  benchmarks  in  SE S/workbench.  Given  the  previous  descriptions 
of  the  benchmarks,  these  graphs  should  provide  enough  detail  to  understand  how  the 
benchmarks  were  realized  in  the  SES  tool. 
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Figure  11.  (continued) 
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Figure  11.  (concluded) 
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APPENDIX  C 


Sim++  CODE 


II  III  III  Testl.c  --  testl  (1  queue) 
♦include  <slm++.h> 

•include  <stdlib.h> 

//  message  types 
wud  (  I  NIT,  00,  STOP); 

//  receiver  entity  class 
class  too  :  public  sim_entity  { 
public: 

foo (  sim_event  iev) ; 
void  body!) ; 
void  bir() > 


foo::foo(  sim_event  &erv ) 

( 

//  initialize  the  entity 
) 

void  foo:  :body () 

( 

sim_event  evi 
sinv_wait(  ev)  f 

while  (  ev. typed  I-  STOP  )  { 
bard  ; 

sim_wait (  ev) ; 

) 

) 

void  foo: : bard  { 

) 


//  instantiate  entity  class 
SIH_ENTITY  ( foo) ; 

//  id  for  entity  instantiation 
Bim_entity_ld  foo_ld; 

//  source  entity  class 
class  source  :  public  eim_entity  { 
public: 

source!  sim_event  fcerv) ; 
void  body  ( )  ; 
private: 
int  n; 

): 

source: : source!  sim_event  tev) 

( 

//  get  the  number  of  iterations 
SIH_GET(  int,  n,  ev) ,- 

) 

void  source: : body!) 

( 

//  Put  n  events  on  queue, 
int  seed  -  12345: 
double  time: 
while  (n — ) 

( 

time  *  sim_uni form (  1.0,  1000.0,  seed) ; 
sim_schedule( foo_id,  time,  00); 

) 

//  Schedule  the  stopping  event 
sim_schedule (  foo_id,  1001.0,  STOP): 

) 

//  instantiate  entity  class 


SIK_ENTITO (source) ; 

II  id  for  entity  instantiation 
sim_entity_id  source_id; 


II  create  and  initialize  entities 

void  sim_initiallze(  int,  char  *argv[],  int,  char*!]) 

t 

int  n  «  atoi ( argv [ 1 ] ) ; 

char  *foo_name  -  •foo_entity‘; 

char  *source_name  »  •source_entity’: 

//  create  one  instance  of  source  class  with  ID 
source_id  and  name 
//  source_name 

source_id  •  sim_create( "source', eource_name, 
INIT,  SIM_P0T(  int,  n)); 

//  create  one  instance  of  foo  class  with  ID 
foo_id  and  name  foo_name 

foo_id  *  sim_create(  ■foo*,  foo_name,  INIT) ; 

) 


///////////  test lb. c  —  test  1  (n  queues) 
///////////  note:  must  subtract  the  results 
///////////  testlc  in  order  to  remove  the 
///////////  the  overhead  of  creating 
II II I II  III  I  n  entitles 
•include  <sim++.h> 

•include  <stdlib.h> 

•define  haxjnitties  ioooo 

//  message  types 
enun  1  INIT,  00,  STOP); 

//  receiver  entity  class 
class  foo  :  public  sim_entity  ( 
public : 

foo  (  sim_event  iev)  ; 
void  body  ( ) ; 
void  bar ( ) ; 

); 


foo: : foo(  sim_event  Sew) 

( 

II  initialize  the  entity 
) 

void  foo: :body( ) 

( 

sim_event  ev; 
sim_wait(  ev); 

while  (  ev. typed  STOP  )  ( 
bard  ; 

sim_wait  (  ev)  ,* 

) 

) 

void  foo: :bar()  ( 

) 


II  instantiate  entity  class 
SIH-ENTITY  (foo)  ; 

II  id  for  entity  instantiation 
slm_entity_id  foo_id(MWUUnTIES]  ; 


53 


struct  sizes  ( 
int  m; 
lnt  n; 

); 

//  source  entity  class 
class  source  :  public  slm_entity  ( 
public: 

source (  sim_event  tev); 
void  body  0 ; 
private: 

sizes  size; 

); 

source:: source!  sim  event  tev) 

I 

//  get  the  number  of  iterations 
SIM  GET (sizes,  size,  ev) ; 

1 

int  seed  -  12345; 

void  source: : body () 

( 

//  Put  n  events  on  queue 
double  time; 

for  (lnt  n_events  -  size.n;  n_events  >  0; 
n_events — )  ( 

for  (  int  m_entitles  -  slze.m;  m_entities  >  0; 
m_entitles — )  ( 

time  -  sim  uniform!  1.0,  1000.0,  seed); 
sim_schedule (fooid [m  entitles] ,  time,  GO); 

) 

) 


//  instantiate  entity  class 
SIM_ENTITY  (source)  ; 

//  Id  for  entity  Instantiation 
slm_entity__id  source_id; 


//  create  and  Initialize  entitles 

void  sim  initialize!  lnt,  char  *argv(I,  lnt,  char*[|] 

< 

sizes  size; 

slze.m  -  atoi (argv [1 ) ) ; 
size.n  «  atoi (argv [2 )) ; 
char  f oo jname [101; 

char  * source_name  -  "source_entlty"; 

//  create  one  instance  of  source  class  with  name 
source_entity 

sim  create ("source", source  name,  INIT, 
SJM_PUT7»lzes,  size)); 

//  create  "m"  instances  of  foo  class  with  name 
foo  "1" 

~for  (  lnt  1  -  1;  1  <-  slze.m;  1++)  ( 
sprlntf (foo_name,  "foo_%d",  i); 
foo  ld[l)  --sim_create(  "foo",  foo_name,  INIT); 

1 

) 

/////////  testlc.c  —  testl  (n  queues) 

/////////  note:  schedules  no  events, 

/////////  used  to  measure  the  overhead 
/////////  of  creating  n  entities 
•include  <sim++.h> 

•Include  <stdllb.h> 

•define  MhX_ENTITIES  10000 

//  message  types 
enum  (  INIT,  GO,  STOP); 

//  receiver  entity  class 
class  foo  :  public  sim_entity  ( 
public: 

foo (  slm_event  tev) ; 


void  bodyf); 
void  bar()  ; 

); 


foo:: foo (  sim_event  tev) 

l 

//  initialize  the  entity 
1 

void  foo:: body!) 

I 

sim_event  ev; 
sim  wait (  ev) ; 

while  (  ev. typed  !“  STOP  )  ( 
bard; 

sim_wait (  ev) ; 

) 

) 

void  foo::bar()  { 

I 


//  instantiate  entity  class 
SIM_ENTITY (foo) ; 

//  id  for  entity  instantiation 
slm_ent lty_ld  f oo_ld [MAXJENTITIES 1 ; 

//  source  entity  class 
class  source  :  public  sim^entity  ( 
public: 

source (  sim_event  tev) ; 
void  body  () ; 
l; 

source: : source (  simevent  tev) 

[ 

I 

void  source : : body ( ) 

( 

1 

//  instantiate  entity  class 
SIM_ENTITY (source) ; 

//  id  for  entity  Instantiation 
sim_ent lty_ld  source_id; 


II  create  and  initialize  entities 

void  sim  initialize!  lnt,  char  *argv[),  lnt,  char*U) 

( 

int  m  -  atoi  (argv[l)); 
int  n  -  atoi (argv [2] ) ; 
char  foo_name[10]; 

char  *source_name  -  "source_entlty"; 

//  create  one  instance  of  source  class  with  name 
source_entlty 

slm_create ("source", source_name,  INIT) ; 

//  create  “m"  Instances  of  foo  class  with  name 
foo  "1" 

for  (  int  1  -  1;  1  <•  m;  i++)  ( 
sprlntf (foo_name,  "foo  %d",  i); 
foo  id[i)  -  sim_create7  "foo",  foo_name,  INIT) 
I 

I 

llllll  test 2. c 
•include  <sim++.h> 

•include  <stdllb.h> 

//  message  types 
enum  (  INIT,  GO,  STOP); 

//  id  for  entity  instantiation 
sim_entlty_id  foo_id; 
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bar(n) ; 


//  receiver  entity  class 
class  foo  :  public  sim_entity  { 
public: 

foo  (  sim_event  sev) ; 
void  body(); 
private: 
int  n; 

I; 


foo:: foo (  sim  event  sev) 

I 

//  initialize  the  entity 
SIM  GET (  int,  n,  ev); 

) 

void  foo :: body () 

( 

sim  event  ev; 
whiTe  (  — n  ) 

( 

//  schedule  an  event  for  yourself 
sim  schedule (foo  id,  0.0,  GO); 

~ll  and  wait  for  it 
slm_wait  (  ev) ; 

) 

) 

//  instantiate  entity  class 
SIM  ENTITY(foo)  ; 

//  create  and  initialize  entities 
void  siminitialize <  int  argc,  char  *argv[],  int, 
char* [ ) ) 
l 

int  n  -  atoi (argv[l] ) ; 

char  *foo_name  -  "fooentity"; 

//  create  one  Instance  of  class  foo  with  ID 
foo_ld  and  name  foo_name 

foo_ld  -  sim_create(  "foo",  foo  name,  INIT, 
SIM_PUT(~int,  n)); 


) 

//////  test3a.c 
•include  <sim++.h> 

•include  <stdllb.h> 

//  message  types 
enure  (  INIT,  GO,  STOP  I; 

//  id  for  entity  instantiation 
sim_entlty_ld  foo_ld; 

//  receiver  entity  class 
class  foo  :  public  simentity  ( 
public: 

foo (  8lm_event  sev) ; 
void  body  ()  ; 
void  bar  (int); 
private: 
int  n; 

); 

foo::foo(  sim  event  sev) 

( 

SIM_GET(  int,  n,  ev) ; 

) 

void  foo::body() 

( 

bar  (n); 

I 

void  foo::bar(int  n)  ( 

/*sim_printf ("bar:  %d  \n",  n);*/ 
if  (—  n  —  0)  ( 

sim_event  ev; 

sim_time  new_time  -  sim_hold(  1.0,  ev); 

) 

else 


1 

II  Instantiate  entity  class 
SIM_ENTITY (foo) ; 

//  create  and  initialize  entities 

void  sim_lnltialize (  int,  char  *argv[),  int,  char*!]) 

( 

int  n  -  atoi (argv(l) ) ; 

char  *foo_name  -  "foo_entity"; 

//  create  one  instance  of  class  foo  id  ID  foo_id 
and  name  foo_name 

foo_id  •  sim_create (  "foo",  foo_name,  INIT, 
SIM_PUT (  int,  n> > ; 

) 


II II I  test3b.c 
•include  <slm++.h> 

•Include  <stdlib.h> 

//  message  types 
enum  {  INIT,  GO,  STOP); 

//  id  for  entity  instantiation 
sim_entity_id  foo_id; 

//  receiver  entity  class 
class  foo  :  public  sim_entity  ( 
public: 

fool  sim_event  sev); 
void  body ( ) ; 
void  bar  (int); 
private: 
int  n; 

I; 

foo: : foo (  simevent  sev) 

1 

SIM  GET (  int,  n,  ev) ; 

) 

void  foo::body() 

( 

bar  (n) ; 

> 

void  foo::bar(int  n)  ( 
sim  event  ev; 
if  (— n  >  0)  ( 

sim_time  new_time  «  sim_hold(  1.0,  ev) ; 
bar  (n)  ; 

) 

1 

//  instantiate  entity  class 
SIM_ENTITY(foo)  ; 

//  create  and  initialize  entities 

void  slm_lnitlalize (  int,  char  *argv[),  int,  char*[]) 

( 

int  n  -  atoi <argv[l) ) ; 

char  *foo_name  -  “foo_entlty"; 

//  create  one  instance  of  class  foo  id  ID  foo_id 
and  name  foo_name 

foo_id  -  sim_create(  "foo",  foo_name,  INIT, 
SIM_PUT(  int,  n)); 

) 

lllllllllllllllllllllllllllllll  resources. h 
•Include  <sim++.h> 
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) 


//  resource  entity  superclass 
class  resources  :  public  sim_entity  ( 
public: 

//  message  types 

enum  (  INIT,  GIVE,  GIVE_ACK,  TAKE_BACK,  DESTROY); 
//  Initialize  an  Instance 
resources (  sim_event  lev) ; 

//  simple  behaviour 
void  body!); 

slm_event  next_glve_or_destroy () ; 
sim_event  next_take_back_or_destroy (sim_entity_ld 
from) ; 

); 

//  customer  entity  class 
class  consumers  ( 
public: 

void  acquire_resource (  sim_entity_ld 
tthe_resource) ; 

void  give_back_resource <  slm_entity_id 
itheresource) ;  ~ 

void  destroy_resource (  sim_entlty_ld 
Ithere source) ; 

); 

///////////////////////  consumers. c 
•include  "resources. h"; 

void  consumers: :acqulre_resource(  slm_entlty_ld 
ithe_resource) 

( 

const  sim_type_p  got_lt (  resources: :GIVE_ACK) ; 
slm_event  ev; 
sim_event_ld  eventld; 

event_ld  -  sim_schedule (  the_resource,  0.0, 
resources: :GIVE) ; 

slm_walt_for (  gotit,  ev); 

I 

void  consumers ::give_back_resource(  slm_entlty_ld 
tthe_resource) 

(  " 

slmevent  ev; 

sim~event_ld  eventld  *  sim_schedule (  theresource, 

0.0, 

resources: :TAKE_BACK) ; 

) 

void  consumers:: destroy_resource(  sim_entlty_ld 

lthe_resource) 

t 

slm_event  Id  event_ld  *  sim_schedule (  the_resource, 

0.0, 

resources : :DESTR0Y) ; 

) 

///////////////////  resources. c 
•Include  " resources. h"; 

resources: : resources (  slm_event  tev) 

I  //  no  need  to  Initialize  further 
) 

slm_event  resources: :next_glve_or  destroy  () 

I 

const  sim_type_p  glve_or_destroy_p(  GIVE,  DESTROY); 
slm_event  event _recelved; 

//  try  to  select  a  deferred  event  that  matches 
lnt  bool  -  sim_select (  SIM_ANY,  event_received) ; 

If  (bool  —  0)  I 

//  no  deferred  events,  wait  for  next  GIVE  or 
DESTROY 

slm_walt_for (  glve_or_destroy_p, 
event_recelved) ; 

) 

else  |  //  check  that  deferred  event  Is  a  GIVE  or 
DESTROY 

If  ( (event  recelved. typed  !-  GIVE)  it 
(event_recelved.type 0  !-  DESTROY))! 
slm  error ("Unexpected  event  type:  %d  received 
In  resource  ¥s", 

event_recelved. type () ,  slmname); 


I 

return  event  received; 

) 

slm_event 

resources : : next_take_back_or_destroy (slm_ent lty_ld 
from) 

I 

const  sim_type_p  take_back_or_destroy_p(  TAKE_BACK, 
DESTROY)  ; 

sim_event  event_received; 

sim_wait_for (  take_back_or_destroy_p, 
event_received) ; 

lf~(  event_received. type ()  --  TAKE_BACK  )  ( 

if  (  event_recelved.scheduled_by ()  !-  from)  ( 
slm_error (“Entity  other  than  consumer  has 
given  back  resource  %s  \n“, 
slm  named); 

) 

I 

return  event  received; 

) 


void  resources: :body () 

( 

sim_event  next_event; 
sim_entity_id  resourcerequestor; 

next_event  -  next_glve_or_destroy () ; 
while  (next_event.type ()  —  GIVE  )  ( 

//  DESTROY  results  in  termination 

resource_requestor  •  next  event . scheduledby () ; 
//  give  the  resource  to  tKe  requestor 
sim_schedule (  resource_requestor,  0.0, 

GIVE  ACK) ; 

~  //  wait  for  a  request  to  give  It  back  from  the 
requestor 

next  event  - 

next  take  Back  or  destroy  (resource_reguestor) ; 

~  If  Tnext^event. typed  !-  DESTROY)  ( 

next  event  -  next_glve_or_destroy(); 

! 

i 

) 


//////test4.c 

•include  " /home/ vtg/slm++/reusable/ resources. h“; 
•include  <stdlib.h>; 

//  message  types 
enum  (  INIT,  GO,  STOP); 

//  instantiate  the  class 
SIM_ENTITY (resources) ; 

//  handle  for  the  one  instance 
sim_entity_id  resource_id; 


//  customer  entity  class 

class  customer  :  public  sim_entlty,  public  consumers  ( 
sim_tlme  starting_delay; 
public: 

customer!  slm_event  lev)  ; 
void  body  () ; 

); 

customer: : customer (  slm_event  lev) 

( 

//  initialize  the  entity 

SIM  GET(  slm  time,  starting_delay,  ev); 

I  " 

void  customer::body(> 

{ 

sim  event  ev; 
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sim_hold_for(  start  ing_delay,  SIM_NONE,  ev); 
acquire  resource (  resource  id) ; 
sim_hol3  for<  1000000.0,  sTm_N0NE,  ev)  ; 
give_bacf_resource (  resource_id) ; 

) 

//  instantiate  entity  class 
SIM_ENTITY (customer) ; 


//  create  and  initialize  entities 

void  sim  initialize)  lnt,  char  *argv[)»  int,  char**) 

I 

int  n  -  atoi (argv[l) ) ; 

char  *res_name  -  “resource_entity“; 

char  *customer_name  -  “customer_entity“; 

//  create  one  Instance  of  resource  class  with  ID 
resourceld  and  name 
//  resource_name 

resourceld  -  simcreate (“resources", res_name, 
resources :: INIT) ; 

//  create  n  Instances  of  customer  class  with  name 
custcmer_%i 

for  (  int  i  -  1;  1  <-  n;  i++)  ( 

sprint f(  customer_name,  “customer_%d“,  i); 
sim_time  startdelay  -  1; 

slm_create(  “customer",  customername,  INIT, 
SIM  PUT (  sim  time,  start  delay)); 

) 

) 


) 

//  instantiate  entity  class 
SIM_ENTITY (fool ; 

//  create  and  initialize  entities 

void  sim_inltialize (  lnt,  char  *argv(],  int,  char*U) 

I 

int  n  -  atoi  (argv[l )) ; 

char  *foo_name  -  “foo_entity“; 

//  create  one  instance  of  class  foo  id  ID  foo_id 
and  name  foo_name 

foo_id  -  sim_create(  "foo“,  fooname,  INIT, 
SIM_PUT (  int,  n)); 

) 


//////  tests. c 
•include  <sim++.h> 

•include  <stdllb.h> 

//  message  types 

enum  (  INIT,  INTERRUPT,  STOP); 

II  Id  for  entity  instantiation 
slm_entlty_ld  foo_id; 

//  receiver  entity  class 
class  foo  :  public  slm_entity  ( 
public: 

foo(  slm_event  sev) ; 
void  body(); 
void  tripper (); 
void  trippeeO; 
private: 
int  trips; 

I; 

foo:: fool  simevent  *ev) 

( 

SIM_GET(  lnt,  trips,  ev) ; 

) 

void  foo::body() 

( 

trippeeO  ; 

) 

void  foo:  :trlpper()  ( 

slm_schedule(  sim_current () ,  1.0,  INTERRUPT); 

) 

void  foo: :trlppee () 

( 

const  slm_type_p  interrupt (  INTERRUPT) ; 
sim  event  ev; 
whiTe  (0  <  trips — ) 

( 

//  set  the  time  out  timer 
tripper  ()  ; 

//  wait  for  a  long  time  (anticipating  interrupt) 
slm_hold_for(  100.0,  Interrupt,  ev) ; 

) 
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Sim++  BANK  SIMULATION  DESCRIPTION 


The  bank  simulation  in  Sim++  is  the  most  complex  of  our  benchmarks,  and  we  include  here 
some  discuss  before  we  list  the  source  code.  Figure  12  summarizes  the  event  flows  between 
entities  in  the  simulation.  Event  flows  are  labelled  with  corresponding  event  identifiers.  The 
termination  of  event  flows  are  labelled  with  the  method(s)  invoked  by  the  receiving  entity's 
body  method.  The  summary  entity,  the  initialization  event  flows,  and  the  report  event  flows 
are  not  shown  in  the  figure.  Not  all  methods  are  shown. 


Figure  12.  Major  Entities  and  Event  Flows 


Six  entity  classes  are  used  in  the  program: 


1 .  CustomerGenerator.  An  instance  of  this  class  generated  customers  with  a  negative 
exponential  interarrival  time.  The  customer’s  gender  and  ID  were  assigned  at  this 
time.  The  customer  is  sent  to  the  line  determined  by  the  customer's  BestLine  method. 

2 .  VipGenerator:  An  instance  of  this  class  generated  VIPs  with  a  negative  exponential 
interanival  time.  The  VIP's  ID  was  assigned  and  the  VIP  was  sent  to  a  randomly- 
determined  teller. 

3.  LineEntity:  One  instance  of  this  class  was  associated  with  each  teller.  This  entity 
class  modeled  the  line  in  which  the  customers  waited  until  a  teller  was  busy  or  until 
their  "restroom  tolerance"  was  exceeded.  In  addition  to  the  required  constructor  and 
body  methods,  the  following  additional  methods  were  defined: 

a)  PendingN umber:  This  method  determined  the  line  length. 

b)  CheckUneLength:  This  method  replied  to  a  query  for  the  length  of  a  line. 

c)  WaitingCustomer:  This  method  handled  the  arrival  of  a  customer  on  line.  If  the 
line  were  empty  and  the  teller  were  free,  the  customer  would  be  sent  to  the  teller 
for  service.  Otherwise,  the  customer  would  be  enqueued  and  the  customer's 
ArrivedOnLine  method  would  be  invoked  to  schedule  a  timeout  for  its  restroom 
break. 

d)  CustomerTimeout:  This  method  handled  the  occurrence  of  a  restroom  time  for  a 
customer.  The  customer  was  dequeued  and  sent  to  the  restroom  appropriate  to 
the  customer's  gender. 

e)  TellerBusy:  This  method  handled  an  event  that  indicated  that  a  line's  teller  was 
busy. 

f)  TellerFree:  Conversely,  this  method  handled  the  event  that  indicated  that  a 
line's  teller  was  free.  If  any  customers  were  in  line,  the  head  of  the  line  was 
removed,  the  customer's  LeavingLine  method  was  invoked  in  order  to  cancel 
the  corresponding  restroom  timeout  event,  and  the  customer  was  sent  to  the 
line. 

g)  UpdateStats:  This  method  was  invoked  when  the  length  of  the  line  was 
changed  so  that  the  time-averaged  line  length  could  be  accumulated. 

h)  WriteReport:  This  method  reported  the  accumulated  line  length  statistics  to  the 
summary  entity  for  consolidation  and  printing. 
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4.  TellerEntity:  Instances  of  this  class  were  created  to  model  the  bank's  tellers.  In 

addition  to  the  constructor  and  body  methods,  five  methods  were  defined: 

a)  GetNextEvent:  This  method  informs  the  corresponding  line  that  the  teller  is  free 
and  waits  for  the  arrival  of  a  customer  or  VIP. 

b)  ServiceCustomer:  This  method  determines  the  service  time  of  a  customer 
according  to  an  Erlang  distribution  and  attempts  to  service  the  customer  for  that 
time.  This  service  may  be  interrupted  by  the  arrival  of  a  VIP,  at  which  time  the 
ServiceVip  method  is  invoked.  After  return  from  this  method,  the  teller 
attempts  to  give  the  customer  the  remaining  service  time  that  it  needs.  Service 
time  data  for  the  customers  is  accumulated. 

c)  ServiceVip:  This  method  determines  the  service  time  required  by  a  VIP 
according  to  an  Erlang  distribution  and  attempts  to  service  the  VIP  for  that  time. 
If  interrupted  by  the  arrival  of  another  VIP,  the  TurnAwayVip  method  is 
invoked.  After  interruption,  service  is  resumed.  Service  time  statistics  are 
accumulated. 

d)  TurnAwayVip:  This  method  refuses  service  to  VIPs  that  attempt  to  intemipt  the 
service  of  other  VIPs.  A  count  of  the  number  of  VIPs  turned  away  is 
accumulated. 

e)  Write  Report:  This  method  reports  the  accumulated  statistics  to  the  summary 
entity. 

5 .  RestroomEntity:  An  instance  of  the  restroom  entity  class  modeled  the  restroom  for 

each  gender.  Each  restroom  is  a  single-queue  multi-server.  The  methods  defined  in 

addition  to  the  constructor  and  body  methods  are: 

a)  PendingN umber:  This  method  was  reported  the  line  length. 

b)  HandleRestroom:  This  method  handled  the  arrival  of  a  customer.  If  there  was 
no  queue  and  a  stall  was  free,  the  stall  would  be  marked  busy  and  the  service 
time  for  the  customer  would  be  determined  according  to  an  Erlang  distribution. 
A  corresponding  completion  event  would  be  scheduled.  Otherwise,  the  line 
length  would  be  checked  against  the  customer's  line  length  tolerance.  If  this 
tolerance  was  exceeded,  the  customer  would  exit  the  bank.  A  count  of  these 
customers  was  accumulated.  If  the  tolerance  were  not  exceeded,  the  customer 
would  be  enqueued. 

c)  HandleUnoccupy:  This  method  handled  the  completion  event  for  a  customer. 
The  customer  is  sent  to  the  line  entity  with  the  best  line  length  as  determined  by 
the  customer's  BestLine  method.  The  corresponding  stall  is  marked  free.  If 
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there  are  customers  enqueued,  the  head  of  the  queue  is  removed,  the  stall  is 
marked  occupied,  and  a  completion  event  is  scheduled  according  the  service 
time  determined  by  an  Erlang  distribution. 

d)  UpdateStats:  This  method  was  called  when  the  line  length  changed  in  order  to 
accumulate  the  line  length  averaged  over  time. 

e)  WriteReport.  This  method  reports  the  accumulated  statistics  to  the  summary 
entity. 

6.  Summary:  One  instance  of  this  entity  class  was  used  to  consolidate  and  print  the 
statistical  information  for  the  simulation  run. 

Twelve  event  types  were  defined: 

0.  INTTEV.  This  identifier  was  used  for  all  "initialization  events"  sent  to  each  entity 
during  the  Sim++  initialization  phase.  "Init"  object  classes  were  defined  for  each  of 
the  entity  classes  that  contained  the  data  values  necessary  to  identify  or  customize 
each  entity  instance.  Objects  of  the  appropriate  "init"  class  were  included  in  each 
event  sent  by  the  siminitialize  method  to  each  created  entity. 

1 .  CHECKLINE  EV.  This  event  requested  that  the  receiving  line  entity  report  its  line 
length  to  the  sending  generator  entity.  The  body  of  these  events  were  null. 

2 .  UNELENGTHEV.  In  response,  a  line  entity  would  include  an  int  value  in  an 
event  with  this  identifier. 

3 .  CUSTOM  EREV.  Customers  were  sent  between  entities  in  events  with  this 
identifier.  The  body  of  these  events  contained  an  instance  of  the  CustID  class. 

4.  TIMEOUT _EV.  When  arriving  on  line,  a  customer  would  send  an  event  with  this 
identifier  to  the  corresponding  line  entity  that  would  arrive  at  the  entity  if  the 
customer's  "restroom  tolerance"  were  exceeded.  The  body  of  these  events  contained 
a  copy  of  the  CustID  generating  the  event. 

5 .  VIP  EV.  The  arrival  of  a  VIP  was  indicated  by  the  receipt  of  an  event  with  this 
identifier.  The  body  of  the  event  would  contain  an  object  of  the  VipID  class. 

6.  UNOCCUPY _EV.  The  RestroomEntity  entities  scheduled  events  with  this  identifier 
to  indicate  the  time  when  service  for  a  customer  would  be  completed.  The  bodies  of 
these  events  contained  the  customer  objects. 

7 .  BUSYEV.  The  TellerEntity  entities  sent  events  with  this  identifier  to  their 
corresponding  LineEntity  entities  to  indicate  that  they  were  busy  servicing  a  customer 
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or  a  VIP.  This  event  was  necessary  because  the  arrival  of  VIP  at  an  otherwise  free 
teller  should  block  the  normal  customer  from  arriving.  The  body  of  these  events 
were  empty. 

8 .  FREEEV.  Conversely,  this  event  indicates  to  a  LineEntity  that  the  corresponding 
TellerEntity  is  free  and  that  the  next  customer,  when  available,  should  be  sent  to  the 
teller. 

9 .  REPORT _EV.  Events  with  this  identifier  were  used  by  the  Summary  entity  to 
request  statistics  from  the  other  entities. 

10.  REPORT  REPLY.  The  responses  were  returned  to  the  Summary  entity  in  events 
with  this  identifier.  These  responses  contained  objects  of  classes  associated  with  the 
entity  responding. 

1 1 .  LASTEV.  An  event  with  this  identifier  was  sent  by  each  generator  to  indicate  that 
the  simulation  end  time  was  exceeded  and  that  the  summary  statistics  should  be 
collected  and  printed. 

Several  C++  classes  were  developed  that  were  not  Sim++  entity  classes: 

1.  CustID:  This  class  carried  that  data  associated  with  each  customer.  It  was  carried  as 
the  body  in  several  types  of  events.  Other  than  a  constructor,  it  has  methods: 

a)  BestLine:  This  method  determines  the  line  with  the  shortest  length. 

b)  Arrived  On  Line:  This  method  determines  the  customer’s  restroom  tolerance 
and  schedules  a  TIMEOUT _EV  event. 

c)  Leaving  Line:  This  method  cancels  the  TIMEOUT _EV  event  scheduled  when 
the  customer  arrived. 

d)  Service  Started:  This  method  saves  the  start  of  service  by  the  teller  for  later 
statistics. 

2 .  VipID:  This  class  carries  the  data  associated  with  the  VIPs  and  was  carried  in  the 
body  of  events  with  the  VIP_EV  identifier.  The  constructor  was  the  only  method 
defined. 

3 .  my  tally:  This  class  was  a  modification  of  the  Sim++-provided  class  tally.  It  added 
an  operators-  method  that  efficiently  consolidates  the  statistics  gathered  by  two 
instances. 
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Sim++  BANK  SIMULATION  CODE 


//////  bank  simulation 


//////  bank.h 
(include  <aii*++  .h> 

(ifndef  BANK_H 
(define  BAMC_H 

const  HAXJLINE_LEN  .  lOOOOi 
const  KAX_LINES  .  20; 

const  MAXNIM  •  20 1 

const  LEVEL1  •  0) 

const  MIN_CNQ  .  100 ; 

anua  Gender  (Female,  Male) ; 
anum  TellerState  (  Free,  Busy) t 

anum  (  INIT_EV, 

CHECKLINELEV, 

LIt®UHGTH_EV, 

CUSTOMERJV, 

TIHBOUT_EV, 

VIP_EV, 

UNOCCUPY _EV, 

BUSY _EV, 

FREE_EV, 

REPORT _EV, 

REPORT _REPLY, 

LAST _EV  )( 


//  global  parameters 

extern  double  hours.to^run; 

extern  int  numlines; 

extern  int  numreets ; 

extern  slm_eotity_id  line_ld(MM(_LINES+l] , 

extern  slm_entity_id  rest_ld(2]; 

extern  eim_entity_id  teller_id[MkX_LINES+l] ; 

extern  slm_entity_id  cust_g_Ad; 

extern  alm_antity_id  vlp_g_ld; 

extern  slm_entlty_id  sutmary.id; 

int  llne_length[MM(_LINES+l]; 

(endif 


mill  custid.h 
(ifndef  CUSTID_H 
(define  CUSTID_H 
(include  "bank.h* 


//  Customer  id.  object  class 
class  CustID 
( 

slra_event_id  timeout_event; 
public: 

Gender  gender; 

int  line,  id,  toilet; 

8lm_time  on_queue,  serviceustarti 
CuatIDO  (line  >0;  id  »  0;  toilet  •  0;  cn_queue  < 
0 ;  service _start  ■  0 ; ) 
int  Best Line! ) ; 

void  Arrived_on_Line(sim_erlang_obj 
*timeout_generator)  ; 
void  LeavlngJLinel ) , 
void  Service-Started!)  , 

)i 

SIM_DECIARE_LIST  (CustID)  ; 


class  VipID 


( 

public: 
int  line; 
int  id; 

VipIDO  (  line  «  0;  id  -  0;  ) 

); 

(endif 


lllll  generator. h 
(include  "bank.h* 


//  Cu sterner Source  object  declaration 
claas  CustcnerGeneratorlnit 
( 

public: 

int  gender_seed; 
double  arrival_rate; 
int  arrival_seed; 

); 

class  CustomerGenerator  :  public  sim_entity 

sim_randint_obj  gender  generator: 
sia_negexp_obj  lnterarrlval  time  generator; 
public: 

CustomerGenerator  (siSLjevent  4ev) ; 
void  body ( ) ; 

); 

SIH-QHTM  (CustomerGenerator) ; 


II  VipSource  object  declaration 
class  VipGeneratorlnit 
( 

public: 

int  line_seed; 
double  arrival-rate; 
int  arrival _aeed; 

) ; 

class  VipGenerator  :  public  sim_entity 
( 

a  im_randint_ob j  1  i  ne  generato  r  ■, 
s ia__negexp_ob j  interarrival_time_generator; 
int  vip_generated; 
public: 

VipGenerator (sim_event  4ev) ; 
void  body ( ) ; 

); 

SIRJjfnTY  (VipGenerator)  ; 


lllll!  line.h 
(include  "bank.h" 

(include  "custid.h" 

(include  "ny_tally .h" 

//  Line  object  initialization  parameters 
class  Linelnit 
( 

public: 
int  ID; 

siav_erlang_obj  »timeout_generator; 

); 

//  Line  object  stats  class 
class  LineStats 
( 

public: 

sim-accum  cust_online; 
double  laat_evant_time; 
my_tally  cust_waiting_time: 

); 
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//  Line  object  entity  declaration 
class  LineEntlty  :  public  slm_entity 
I 

int  ID; 

TellerState  status; 

CustID_head  'queue; 

LineStats  stats; 

sim  erlangobj  *timeout_generator; 
public: 

LineEntlty (sim  event  t e v )  ; 

void  bodyO; 

int  Pendingtfumber  () ; 

void  CheckLlneLength  (sim_entlty_id  srequester); 

void  WaitlngCustomer (CustID  scustomer); 

void  CustomerTlmeout (CustID  scustomer) ; 

void  TellerBusy () ; 

void  TellerFree () ; 

void  UpdateStats  () ; 

void  WriteReport  () ; 

); 

SIM_ENTITY (LineEntlty); 


////////  my  tally. h 
•include  <slm++.h> 

•  lfndef  MY_TALLY_H 
•deline  MY_TALLY_H 

class  my_tally  :  public  slmtabulate  ( 
double  Sum,  Sumsq,  Min,  Max; 
public: 

mytally  ()  ; 

my  tally (const  char  'title); 

void  reset  ()  ; 

void  update (double  v)  ; 

void  my  tally: :operator+- (my _tally  tally); 
int  obsT)  const  (  return  sim_tabulate: :obs 0 ;  I 
double  avq ( )  const ; 
double  stddev ( )  const ; 
double  min ()  const; 
double  maxi)  const, - 
const  char  'titled  const  (  return 
slmtabulate: :tltle() ;  ) 
vjld  report!)  const; 

void  {report!  const  slm_flle_ld  sflle)  const; 

In¬ 
tend!  f 


////////  restroom. h 
•Include  "bank.h" 

•include  "custid.h" 

//Restroom  Initialization  object 
class  Restroomlnit 
I 

public: 

Gender  gender; 

sim_eriang_obJ  *restroom_service_generator; 
sim_erlang_obj  *restroom_tolerance_generator; 

1; 

//  Res. '0"m  stats  object 
class  RestroomStats 
l 

public: 

Int  customers,  custwalkaway; 
sim_accum  llne_length; 
slm_tlme  lasteventtime; 

); 


public: 

RestroomEntity (sim_event  lev); 

void  bodyi); 

int  PendingNumberO  ; 

void  HandleRestrocm  (sim_event  tev) ; 

void  HandleUnoccupy (sim_event  tev); 

void  UpcIiteStats  0 ; 

void  WriteReport  ()  ; 

); 

SIM_ENTITY  (RestroomEntity)  ; 


//////  summary. h 
•Include  "bank.h* 

//  Sumaary  object  declaration 
class  Sunznary  :  public  slm_entlty 
( 

Int  total_report; 
public: 

Summary (sim^eventt) ; 
void  bodyO? 

); 

SIH_ENTITY  (Sunznary) ; 


/////////  teller. h 
•Include  "bank.h* 

•Include  “custld.h” 

•Include  "my_tally.h" 

//  Teller  Initialization  parameters 
class  Tellerlnit 

I 

public: 
int  ID; 

sim_erlang_obJ  'customer  servicegenerator; 
sim_erlang  obj  'vlpservlcegenerator; 

I; 

//  Teller  Stats  object 
class  TellerStats 
( 

public: 

int  cust_interrupts; 
int  vip_turnaway; 
my_tally  customer  servlce_time; 
my  tally  VIP  servTcetime; 

TellerStats  (T  (  cust  interrupts  -  0;  vlp_tumaway 

0; ) 

I; 

//  Teller  object  entity  declaration 
class  TellerEntity  :  public  sim_entlty 

( 

int  ID; 

sim_erlang_obj  'customer_service_generator; 
sim  erlangobj  *\  ipservlcegenerator; 

TelTerStats  stats;  _ 
public: 

TellerEntity (slm_event  tev); 
void  body!); 

void  GetNextEvent (sim_event  lev); 
void  ServiceCustomer (CustID  customer); 
void  ServlceVip(VipID  VIP); 
void  TurnAwayVlpIVipID  VIP); 
void  WriteReport!); 

); 

SIM_ENTITY (TellerEntity)  ; 


//  Restroom  object  entity  declaration 
class  RestroomEntity  :  public  sim_entity 
( 

Gender  gender; 

CustID_head  *cust_llst; 
int  occupy (MRXLINES+l I ; 
slm_erlang_obJ  'servicegenerator; 
sim_erlang_obJ  'tolerancegenerator; 
RestroomStats  stats; 


//////  bank.c 
•Include  <stdlib.h> 
•include  "bank.h" 
•include  "generator. h“ 
•include  "line.h" 
•include  “restroom. h" 
•include  "teller. h" 
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//  configuration  parameters  of  the  bank 
sim_time  hours  to_run; 
int  num lines; 

int  numrests; 

//  entity  id  for  all  objects 

sim_ent ity_id  line_id [MAX_LINES+1 ) ; 

sim_ent ity_id  rest_id(2); 

sim_ent ity_id  teller_id[MAX_LINES+lJ ; 

sim_entity_id  cust_g~id; 

sim_ent ity_id  vip_g_id; 

sim_ent itv_id  suiranary_id; 


//  customer's  waiting  time  on  a  line  before  leaving 
for  restroom 

//  and  restroom  tolerance 

sscanf  (datav [3] ,  "%lg  %d  %d  %lg  %d  %d",  4tc_mean, 
4tc_sample,  4gtc_seed, 

4rt_mean,  4rt_sample,  4grt_seed); 
restroom_timeout_generator  - 
sim_erlang_obj (“Restroom  timeout", 
tc_mean,  tc_s ample,  gtc_seed) ; 
restroom_tolerance_generator  - 
sim_erlang_obj (“Female  tolerance", 
rt_mean,  rt_sample,  grt_seed) ; 


//  the  common  random  number  generators 
sim_erlang_obj  rest room_t imeoutgenera tor; 
sim_erlang_obj  restroom_service_generator (2J ; 
sim  erlang_obj  restroom_tolerance_generator;  //shared 
by  Both  genders 

sim_erlang_obj  customer  service_generator; 
sim_erlang_obj  vip_servTce_generator; 


double 

cust_arrv_rate, 

int 

gcust_seed; 

double 

v i p_a  r rv_ra  t  e ; 

int 

gvip  seed; 

int 

gline_seed; 

int 

ggende  r_seed ; 

void  readdataf ile (char*  datav(|) 
( 


double 

tcjmean; 

int 

tc  sample ; 

int 

gtcseed; 

double 

rt_mean; 

int 

rt_sample; 

int 

grt  seed; 

double 

rr_mean [2 ] ; 

int 

rr_sample  [2] ; 

int 

grr_seed[2) ; 

double 

cu  st se  rv i ceme an; 

int 

cust_service_samplel 

int 

gcust_service_seed; 

double 

vip_service_mean; 

int 

vipserv i ce_sampl e ; 

int 

gvipserviceseed; 

//  the  randcm  number  parameters  read  from  the  inputs 
//  customer  and  vip  arrival  rates  and  their  seeds 
sscanf  (datav [0 ) ,  "%lg  %d  %lg  %d",  4cust_arrv_rate, 
4gcust_seea, 

4vip_arrv_rate,  4gvip_seed); 

//  customer  and  vip  service  times  (mean,  sample  and 
seed) 

sscanf  (datav (1 ] ,  “%lg  %d  %d  %lg  %d  id", 

4  cus t_serv i ce_mea  n , 

4cust_service_sample,  4gcust_service_seed, 
4vip_service_mean, 

4vip_service_sample,  4gvip_service_seed) ; 
customer_service_generator  * 
sim_erlang_obj ("Customer  Service  Time", 

cust_service_mean,  cust_service_sample, 
gcust_service_seed) ; 

vip_service_generator  -  sim_erlang_obj ("VIP  Service 
Time", 

v 1 p_serv i ce_mea n ,  v i p_se r vi ce  sampl e , 
gvip_service_seed) ; 


//  customer's  time  spent  in  restroom  (mean,  sample 
and  seed) 

sscanf  (datav [2 ) ,  “%lg  %d  %d  %lg  %d  %d“,  4rr_mean[0) 
4rr_sample (0) ,  4grr_seed [0] ,  4rr_mean[l], 
4rr_sample ( 1 ) ,  4grr_seed[l ) j ; 
restroom_service_generator [0]  » 
sim_erlang  obj ("Female  Service" 
rr_m»' m  f  0) ,  rr_sample  [0] , 
restroor  rvicegenerator [ 1 ) 

Service", 

rr  mean[l),  rr  sample (1),  grr_seed ( 1 ) ) ; 


grr_seed (0) ) ; 

-  sim_erlang_ob j ("Male 


//  line  seed  and  gender  seed  for  their  randint 
function 

sscanf  (datav [4 ] ,  "%d  %d“,  4gline_seed, 

4ggender_seed) ; 

//  number  of  lines  in  the  bank,  number  of  toilers  in 
each  restroom 

//  and  number  of  hour  to  run  the  simulation 
sscanf  (datav (5) ,  "%d  %d  %lg“,  4numlines,  4numrests, 
4hours_to_run) ; 

sim_trace (LEVEL1,  "initalizing  all  input 
parameters\n") ; 

) 


void  sim_initialize (int,  char  *(],  int,  char*  datav[)) 

{ 

char  line_name [20) ,  teller_name (20) ,  name (20); 
read_data_f ile  (datav) ; 

sim  trace (LEVEL1,  "creating  line  and  restroom 
entitles\n") ; 

for  (int  i-1;  i<*: :numlines;  i++)  ( 

sprint f (line_name,  "line_ent ity_%d",  i); 

Linelnit  line_init_info; 
line_init_info.ID  -  i; 

1 ine_i n it _ i nfo . t imeout_generator  - 

4  res  t  room_t imeout_genera tor ; 

::line_id[i]  «  sim_create ("LineEntlty",  line_name, 
INIT_EV, 

SIM_PUT (Linelnit, 

line_init_info) ) ; 

sprintf (teller_name,  "teller_entity_%d",  i) ; 
Tellerlnit  teller_init  info; 
teller_init_info. ID  *  T; 

teller_init_info.customer_service_generator  * 
4customer_service_generator; 

teller_init_info. vip_service_generator  • 
4vip_service_generator? 

;  :teller_id(i)  «  sim_create  ("TellerEntity", 
teller_name,  INIT_EV, 

SIM_PUT (Tellerlnit, 

teller_init_info) ) ; 

} 

for  (Gender  j  -  Female;  j  o  Male;  j++)  ( 
sprint f (name,  "restroom_ent ity_%d",  j) ; 
Restroomlnit  rest room_i nit _info; 
restroom_init_info. gender  -  j; 
rest room_init_i nfo. rest room_service_generat or  - 
4restroom_service_generator [ j ) ; 

res t  r oom_ i n i t  _i n  f o . re  st  r oom_t  ole  ra  ncege ner a  t o r  - 
4 res t room_t o ler a nce_gene rat or; 

::rest_id[j]  *  sim_create("RestroomEntity",  name, 
INIT_EV, 

SIM_PUT (Rest roomlnit, 

rest room_init_info) ) ; 

) 

CustomerGeneratorlnit  custgen_init ; 
custgen_init .gender_seed  -  ggender_seed; 
custgen_init .arrival_rate  -  cust_arrv_rate; 
custgen_init .arrival_seed  -  gcust_seed; 
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cust_g_id  -  sim_create (“CustomerGenerator", 
"customer_generator",  INIT_EV, 

SIM_PUT  (CustomerGeneratorlnit, 

custgen_init) ) ; 

VlpGeneratorlnit  vlpgen_init; 
vlpgen_lnit . 1 lne_seed  -  gllne_seed; 
vipgen_init.arrival_rate  »  vip_arrv  rate; 
vipgen  init ,arrival_seed  -  gvip_seed; 
vlp_g_Td  -  slmcreate ("VipGenerator", 
“vip_generator“,  INITEV, 

SIM_PUT (VlpGeneratorlnit, 

vipgeninit) ) ; 

summary_id  •  sim_create (“Summary",  "summary", 
INITEV) ; 

) 


/////////  custld.c 
•Include  "custid.h" 

lnt  CustID:  :BestLine  () 

( 

lnt  bestline; 

int  best len  -  MAX_LINE_L£N; 

for (lnt  line  •  1;  line  <«::  numllnes;  line++)  ( 
If  (line_length{line]  —  0)  I 
bestline  -  line; 
break; 

I 

If  (line_length[linel  <  best len) ( 
bestline  -  line; 
bestlen  -  line_length [line] ; 

1 

) 

return  best line; 

I 

void  CustID: :Arrlved_on_Line (sim_erlang_ob j 
•timeout  generator) 

I 

•  lfdef  INSTRUMENTED 
If  (  on_queue  —  0.0) 
on  queue  -  slm_clock<); 

•  endlf 


double  timeout  -  t imeout_generator->sample () ; 
timeout_event  -  slm_schedule (sim_current () , 
timeout,  TIMEOUT_EV, 

SIM  PUT (CustID,  'this)); 


I 


void  CustID: :Leavlng_Llne() 

( 

sim_cancel (timeout_event) ; 

) 

void  CustID:  :Servlce_Started() 

( 

•  lfdef  INSTRUMENTED 

if  (  service_start  «“  0.0) 
service_start  -  sim_clock(); 

•  endlf 
1 


////////  generator. c 
•Include  "generator. h" 

•Include  “custid.h" 

/* 

••  CustomerGenerator  object  entity  implementation 

*/ 


CustomerGenerator: :CustomerGenerator (sim_event  sev) 

< 

sim_trace (LEVEL1,  "Initializing  customer 
generatorVn") ; 


CustomerGeneratorlnit  lnltinfo; 

SIM  GET (CustomerGeneratorlnit,  lnit_info,  ev); 
genHer_generator  -  sim_randint_obj ("Customer 
Gender",  0,  1, 

inlt  info.gender_seed) ; 

Tnterarrl val_tlme_generator  - 
sim_negexp  obj ("Customer  Interarrival", 

inlt_fnfo.arrival_rate,  inlt_info.arrlval_seed) ; 

) 

void  CustomerGenerator: :body 0 
( 

lnt  total_cust  -  0; 
slm_event  ev; 

sim_time  interarrival_tlme; 

CustID  tag; 

while  (sim_clock()  <•=  :  :hours_to_run*60)  ( 
total_cust  ++; 

sim_trace (LEVEL1,  "Generating  customer  •:  %d\n“, 
total_cust) ; 

tag. gender  -  (Gender)  gender_generator. sample () ; 
tag.  line  ■=  tag.BestLine  0  ; 
tag. id  -  total_cust; 
sim_schedule (: : line  ld[tag.line] ,  0.0, 
CUSTOMER_EV,  SIM_PUT (CustID,  tag)); 

interarrival_time  - 
interarrival_tlme  generator. sample () ; 

slm  hold  for (Xnterarrival  time,  SIMNONE,  ev); 

i  ” 

//Indicate  to  summary  that  no  more  customers  will 
arrive 

slm_schedule  (:  :summary_id,  0.0,  LASTEV, 

SIM_PUT (lnt, totalcust) ) ; 

) 


/* 

**  VipCustomerGenerator  object  implementation 
V 


VipGenerator: : VipGenerator (slmevent  sev) 

( 

sim_trace (LEVEL1,  "entering  vip  constructor1^") ; 
VlpGeneratorlnit  lnlt_lnfo; 

SIM_GET (VlpGeneratorlnit,  initlnfo,  ev) ; 
line_generator  -  slm_randint_obj ("VIP  Line",  1, 
numllnes, 

init  lnfo.llneseed) ; 

rnterarrlval_time_generator  -  slmnegexpobj ("VIP 
Interarrival",  ~ 

init_info.arrival_rate,  lnit_info.arrival_seed) ; 

> 

void  VipGenerator:  :body  () 

( 

int  total_vip  »  0; 

VipID  vip; 
simevent  ev; 

slm”tlme  interarrival_time; 

Interarrival  time  - 
lnterarrlval_tTme_generator. sample () ; 

sim_hold  for (interarrival_time,  SIM_N0NE,  ev) ; 
while  (sTm_clock()  <  : :hours_to_run*60)  ( 

total_vip++; 

sim_trace (LEVEL1,  "Generating  VIP  customer 
•%d\n",total_vip) ; 

vip. line  «  1 ine_generator. sample () ; 
vip. id  -  total_vip; 

sim_schedule (: : teller_id [vip. linej ,  0.0,  VIP_EV, 
SIMPUT (VipID,  vip)); 

interarrival_time  « 
interarrival_time  generator. sampled  ; 

slm_hold_for (Tnterarrival_t ime,  SIM_NONE,  ev); 

I 
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//Indicate  to  summary  that  no  more  customers  will 
arrive 

sim_schedule (: isuimary  id,  0.0,  LAST  £V, 

SIM_PUT (lnt, total  vip) ) ; 

1 


////////  llne.c 
♦include  "llne.h" 

♦include  <stdio.h> 

/* 

**  Line  object  entity  Implementation 

*/ 

LineEntlty: :LineEntlty (slm  event  (ev) 

( 

char  tltle[20); 

simtrace (LEVEL1,  “Line  entity  inltlallzing\n") ; 
Linelnit  inlt_info; 

SIM_GET(LineInit,  init_ln£o,  ev) ; 

ID  -  init_lnfo.ID; 

t imeout  generator  -  init_info.timeout_generator; 
status  -  Free; 

queue  -  new  CustIDhead (“queue") ; 
line_length[ID)  -  0; 

♦  ifdef  INSTRUMENTED 
sprint!  (title,  “Line  %d“,ID); 

stats. cust_online  -  simaccum (title) ; 
stats. last  event  time  -  0; 

♦  endif 
) 

void  LineEntlty;  :body  () 

1 

simevent  ev; 

CustID  customer; 

sim  wait (ev) ; 

while  (ev. typed  !-  REPORT_EV)  ( 
switch  (ev. type  () )  ( 
case  CHECKLINE_EV ; 

CheckLineLength (ev. scheduledby () ) ; 
break ; 

case  CUSTOMEREV: 

SIM_GET (CustID,  customer,  ev) ; 

WaltingCustomer (customer) ; 
break; 

case  TIMEOUT_EV: 

SIM__GET  (CustID,  customer,  ev) ; 

CustomerTimeout (customer)  ; 
break; 

case  BUSYEV: 

TellerBusy () ; 
break; 

case  FREE_EV: 

TellerFreeO  ; 
break; 
default : 

sim_error (“unexpected  event  type  %d  from; 
%s\n",  ev.type () , 

ev. scheduled  by  ()  .name  () ) ; 

) 

sim_select (SIM_ANY,  ev)  ; 
if  (ev  —  SIM_NO_EVENT)  ( 

slm_trace(LEVELl,  “Waiting  for  next  customer  or 
vip\n“); 

slm  walt(ev); 

) 

I 

♦  ifdef  INSTRUMENTED 
WriteReport  ()  ; 

♦  endif 

slm_trace (LEVEL1,  "Line  TermlnatedNn") ; 

) 

lnt  LineEntlty: : PendingNumber () 

t 


if  ((!queue->empty() )  (status  —  Free)) 
return  (queue->cardinal  () )  ; 
else  if  ( (!queue->empty  () )  a  (status  --  Busy)) 
return  (queue->cardinal  0  +1); 
else  if  (status  >-  Busy) 
return  1; 
else 

return  0; 

1 

void  LineEntlty: :UpdateStats() 

t 

♦  ifdef  INSTRUMENTED 

stats. cust_onllne. update (  (sim_clock()  - 
stats. last_event_time) , 

double  (PendingNumber  ())),’ 
stats. last_event  time  -  sim_clock(); 

♦  endif 
1 

void  LineEntlty: :CheckLlneLength(sim_entlty_id 
(requester) 

( 

sim_trace (LEVEL1,  “handling  check  line  event\n“); 

lnt  length  -  PendingNumber () ; 

sim_schedule (requester,  0.0,  LINELENGTH_EV, 

SIM  PUT  (lnt,  length)); 

) 

void  LineEntlty: :WaitingCustomer (CustID  (customer) 

( 

CustID_elem  *elem; 

sim_t race (LEVEL1 ,  “handling  waiting  event\n“); 

//  data  collection,  e.g.  ave.  queue  length 

♦  ifdef  INSTRUMENTED 
UpdateStats () ; 

♦  endif 

//  if  the  line  is  empty  and  the  teller  is  free 
if  ( (queue->empty ()  >  0)  ((  (status  Free))  ( 
//send  directly  to  teller 

♦  ifdef  INSTRUMENTED 

Stats. cust_wait ing_t lme . update (0.0); 

♦  endif 

Sim  schedule (::teller  id [ID],  0.0,  CUSTOMER  EV, 
SIM  PUT (CustID,  customer) F; 

) 

else 

( 

customer. Arrlved_on_Llne (timeout_generator) ;  // 

schedule  restroom 

//  enqueue  the  customer  on  the  line 
elem  -  new  CustID_elem(customer) ; 
elem->append  (queue) ; 
line_length[ID]  ++; 

) 

i 

void  LineEntlty: :CustomerTimeout (CustID  (customer) 
//Customer  may  have  been  on  line  too  long,  needs  a 
trip  to  the  restroom 
I 

CustID  temp; 

CustID_elem  *elem; 

slm  trace (LEVEL1,  "handling  timeout  event\n“); 

//must  search  for  customer  in  queue 
elem  -  queue->first  ()  ; 
while  (elem  !-  0) 

( 

temp  -  elem->contents  ()  ; 

if  (temp. id  ■*  customer. id)  (  //found  customer 
in  line 

//take  off  line 

♦  ifdef  INSTRUMENTED 

UpdateStats () ; 

♦  endif 
elem->out  ()  ; 
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( 


//send  to  restroom 
int  j  •  (lnt)  customer. gender; 
slm_schedule(: :rest_id[ j) ,  0.0,  CUSTCMER_EV, 
SIM_PUT (CustID,  customer)); 
delete  elem; 
llne_length[ID]  — ; 
return; 

) 

else 

elem  -  elem->next () ; 

) 

slm_error ("Couldn't  find  timed  out  customer  in 
line\n"> ; 

) 


void  LlneEntlty : :TellerBusy () 

I 

sim_trace (LEVEL1,  “handling  busy  event\n“); 
status  -  Busy; 

) 

void  LlneEntlty : :TellerFree () 

( 

CustID_elem  “elem; 

CustID  nextCustomer; 

slm_trace (LEVEL1,  "handling  free  event\n") ; 
status  -  Free; 

If  ( !queue->empty  () )  | 

I  ifdef  INSTRUMENTED 
UpdateStats  ()  ; 

#  endif 

elem  -  queue->first  () ; 
elem->out  () ; 

nextCustomer  -  elem->contents  () ; 

nextCustomer. Leavlng_Llne () ;  //  cancel  restroom 

trip 

line  length [ID] — ; 

#  lfdeT  INSTRUMENTED 

stats. cust  waiting _tlme. update (  (sim_clocM)  - 
nextCustomer. onqueue) ) ; 

#  endif 

sim_schedule ( : :teller_id [ID] ,  0.0,  CUSTOMER_EV, 
SIM_PUT (CustID,  nextCustomer)); 
delete  elem; 

1 

) 


void  LlneEntlty : :WrlteReport 0 
( 

slm  schedule  (summary _ld,  0.0,  REPORTREPLy, 
SIM_P(?T(LlneStats,  stats) )  ; 

) 


////////  mytally.c 
•include  "my_tally.h" 

•include  <math.h> 

my_tally: :my_tally  0 :  (“my_tally") 

I 

Sum  -  0.0; 

Sumsq  "  0.0; 

Min  -  1.0eS5;  //  very  large 

Max  -  -1.0e55;  //  very  large  negative 
I 

my _taliy: :my_tally (const  char  ‘title!  :  (title, 
"my_tally") 

I 

Sum  -  0.0; 

Sumsq  *  0.0; 

Min  -  1.0e55;  //  very  large 

Max  -  -1.0e55;  //  very  large  negative 

) 

void  my  tally: :reset () 


slm_tabulate:  .‘reset  ()  ; 

Sum  “  0.0; 

Sumsq  -  0.0; 

Min  -  1.0e55;  //  very  large 

Max  -  -1 . 0e55;  //  verv  large  negative 

( 

void  my _tally: tupdate (double  v) 

I 

sim_tabulate::update_obs() ; 

Sum  +-  v; 

Sumsq  +-  (v*v) ; 

If  (  v  <  Min  )  Min  -  v; 

if  (  v  >  Max  )  Max  -  v; 

) 

void  my_tally: :operator+-(my_tally  tally) 

( 

update_obs  (tally. obs  () ) ; 

Sum  +-  tally. Sum; 

Sumsq  +-  tally. Sumsq; 

if  (  tally. Max  >  Max)  Max  -  tally. Max; 

If  (  tally. Min  <  Min)  Min  -  tally. Min; 

I 

double  my_tally: :avg ()  const 

I 

double  obs  -  doublet  sim_tabulate: :obs () ) ; 
return  Sum  /  obs; 

) 

double  my_tally: :std_dev ()  const 

( 

double  obs  •  doublet  simtabulate: :obs () ) ; 
return  sqrt ( (  (Sumsq  -  (Sum  *  Sum)  /  obs  )/  (obs  - 
1.0)  )); 

) 

double  mytally: :min ()  const  (  return  Min;  ) 

double  my_tally: :max()  const  I  return  Max;  I 

void  my_tally: : report  0  const 
( 

slm  printf ( 

*»12s  »6d  %9.3f  »9.3f  %9.3f  %9.3f  »9.3f 

\n", 

titled , 
obs() , 

Sum, 
avg  () , 
std_dev(), 
min  () , 
max() 

)  ; 

) 

void  my_tally: :freport (  const  sim_file_ld  tfile)  const 
( 

sim_f printf ( 
file, 

"%12s  %6d  %9.3f  %9.3f  %9.3f  %9.3f  %9.3f 

\n“, 

titled, 
obs  () , 

Sum, 
avg () , 
std_dev() , 
min  () , 
max  () 

)  ; 

I 


////////  restroom. c 
•include  "restroom. h" 

•Include  <math.h> 

RestroomEnt ity: : RestroomEnt lty (slm_event  iev) 

{ 
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sim_trace (LEVELl,  “Restroom  Constructor\n“) ; 

Restrooeilnit  init_lnfo; 

SIM_GET(RestroomInit,  inlt_info,  ev) ; 
gender  -  lnit_info. gender; 
servlce_generator  - 
lnlt  lnfo.restroom_servlce_generator; 

toTerance_generator  - 
lnlt_lnfo.restroom_tolerance_generator; 

fordnt  1-1;  K-:  :numrests;  1++) 
occupy (1]  -  0; 

cust_llst  -  new  CustID_head ("cust_llst") ; 

*  lfdef  INSTRUMENTED 
stats. customers  -  0; 
stats. cust  walkaway  -  0; 

If  (gender  --  Female) 

stats. llne_length  -  slm_accum (“Female") ; 

else 

stats. llnelength  -  sim_accum (“Male") ; 
stats. lastevent  time  -  0; 

•  endlf 

I 

void  RestroomEntlty: :body () 

( 

sim_event  ev; 

Cust ID  tag; 

slm  wait (ev) ; 

while  (ev. typed  !-  REPORT_EV)  | 
switch  (ev. type  () )  ( 
case  CUSTOMEREV: 

HandleRestroom(ev) ; 
break ; 

case  UNOCCUPY_EV: 

HandleUnoccupy (ev) ; 
break ; 
default; 

slm  error ("unexpected  event  type  %d  from  ts\n“, 
ev.typef) , 

ev.  scheduled  by  ()  .name  () ) ; 

1 

slm  select (SIMANY,  ev) ; 

If  Tev  —  SIMNOEVENT)  ( 

slm_trace (LEVELl,  "Waiting  for  next  customer  or 
vlp\n“) ; 

slm_wait (ev) ; 

) 

1 

*  lfdef  INSTRUMENTED 
WriteReport () ; 

•  endlf 

slm_trace (LEVEL1,  "Restroom  Termlnated\n") ; 

) 

void  RestroomEntlty :: Handle Rest room (slm  event  tev) 

( 

CustID  tag; 

double  restroom  duration; 
lnt  rest  room  t olerance; 

CustID_elem  "elem; 


SIMGET (CustID,  tag,  ev); 

#  lfdef  INSTRUMENTED 
stats.custoroers++; 
t  endlf 

for  (int  1-1;  1  <-  ::numrests;  i++) 

If  (occupy [ i )  —  0) 
break; 

If  ( (cust_llst->empty 0  >  0)  tt  (1  <-  ::numrests))  ( 
slm_tra~a (LEVEL1,  "restroom  is  avallableXn") ; 
occupy [1]  -  1; 
tag. toilet  -  1; 

restroom_duratlon  -  servlce_generator->sample () ; 


slm_schedule (slm_current () ,  restroom  duration, 
UNOCCUPY_EV, 

SIM  PUT (CustID,  tag)); 

) 

else  | 

sim_trace (LEVEL1,  “there  is  a  line  or  all  toilets 
are  occupiedXn"); 

restroom_tr . erance  -(int)  anlnt ( 
tolerance_generator->sample ()  ); 

if  (PendingNumber ()  >  restroom_tolerance)  ( 

#  lfdef  INSTRUMENTED 

stats. cust_walkaway++;  //  customer  walk  out  of 

bank 

i  endlf 

return; 

) 

else  ( 

//  enqueue  It  on  the  list 
elan  -  new  CustID_elem(tag) ; 
elem->append (cust_list) ; 

<  lfdef  INSTRUMENTED 

UpdateStats  () ; 

#  endlf 

) 

) 

1 

lnt  Rest  roomEnt ity : : PendingNumber () 

( 

return  (cust_list->cardinal () ) ; 

) 

void  RestroomEntlty: : HandleUnoccupy (sim_event  tev) 

( 

CustID_elem  “elern; 

CustID  tag,  temp; 
double  restroom_duratlon; 

SIM_GET (CustID,  tag,  ev); 
tag. line  -  tag.BestLined; 

slm_schedule  (::  line_id  [tag. line] ,  0.0,  CUSTCMER  EV, 
SIM_PUT (CustID,  tag)); 
lnt  1  -  tag. toilet; 
occupy [1]  -  0; 

If  (!cust  llst->empty () )  ( 
occupy [T]  -  1 ; 
elem  -  cust_list->f lrst  ()  ; 
elem->out () ; 

temp  -  elem->contents(> ; 
delete  elem; 
t  lfdef  INSTRUMENTED 
UpdateStats  0 ; 

#  endl f 

restroom  duration  -  service_generator->sample () ; 
slm_scheHule (sim_current () ,  restroom_duration, 
UNCCCUPY_EV, 

SIM_PUT (CustID,  temp)); 

I 

) 

void  RestroomEntlty: :UpdateStats () 

( 

lnt  num  onQ  -  PendingNumber!); 
stats. lTne_length. update ( 

(slm_clock()  -  stats. last_event_tlme) , 
double (num_onQ) ) ; 

stats. lasteventtime  -  sim_clock(); 

I 

void  RestroomEntlty: :WriteReport () 

I 

sim_trace (LEVEL1,  “Writing  Restroom  Report:  Restroom 
%d  \n",  gender) ; 

sim_schedule (summary _id,  0.0,  REPORT_REPLY, 

SIM_PUT (RestroomStats, stats) ) ; 

) 


////////  summary. c 
•include  "summary. h" 
•Include  "line.h" 
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•include  “teller. h“ 

•Include  “restroom. h" 

Summary:  :Summary  <sim_events) 

( 

sim_trace (LEVEL1,  “summary  constructor^")  ; 
totai_report-0; 

) 

void  Sumnary : :body () 

1 

simevent  ev; 

slmfromjp  customer_generator (  : :cust_g_ld) ; 
slm_from_p  vlp_generator (  ::vip_g_id); 
slm_type_p  report_reply  p (R£PORT_REPLY)  ; 

•  ifdef  INSTRUMENTED 
int  number; 

sim_flle_id  report_flle; 

LineStats  line  lengthstats; 

TellerStats  teTler_totals; 

TellerStats  tellerreport; 

RestroomStats  restroom_report; 

//  generate  the  report 

reportfile  -  slm  fopen (“report",  “w“) ; 

•  endif 

//Generators 

//wait  for  both  generators  to  finish 
slm_walt  for(  customer  qenerat or,  ev) ; 

•  ifdef  INSTRUMENTED 
SIM_GET(int,  number,  ev) ; 

sim_fprintf (report_f lie,  “%d  customers  arrlved\n“, 
number) ; 

•  endif 

sim_wait_for (  vlpgenerator,  ev); 

•  ifdef  INSTRUMENTED 
SIM_GET(int,  number,  ev); 

simfprintf (report_f lie,  “»d  VIPS  arrlved\n“, 
number) ; 

•  endif 

//Lines 

//print  the  statistics  for  the  line  lengths 

•  ifdef  INSTRUMENTED 

my  tally  customer_waiting_time("Waltlng  Time"); 
simfprintf  (report_file, 

••_ _ _ _ _ _ _ _ _  __  _ _  _  _  _  _ _ _ 

- \n") ; 

sim  fprintf (report_f lie,  “Line  StatlsticsinLine 
LengtfisNn") ; 

sim_fprlntf (report_file,  : :sim_accum_headlng() ) ; 

•  endi f 

for  (int  1  -  1;  i  <-  ::numlines;  i++)  1 

s im_schedu le ( : : 1 i ne  id t i ] ,  0.0,  REPORT_EV); 

•  ifdef  INSTRUMENTED  ~ 
slm_walt_for (  report  reply_p,  ev) ; 

SIM_GET (LineStats,  iTnelengthstats,  ev); 

llne_iength_stats.cust  online. freport (report_file) ; 

customer_waltlng_tTme  +- 
1 i ne_lengt  h_stat  s.cust_walti ng_t  ime ; 

•  endif 

) 

•  ifdef  INSTRUMENTED 

sim_fprintf (report  file,  : :sim_tally_heading() ) ; 
customer__waiting_tTme.  freport  (report_file) ; 

•  endif 

//Rest rooms 

•  ifdef  INSTRUMENTED 

int  total_customers  ■  0; 

int  total_customers  walking_away  -  0; 

slm_fprintf (report_7ile, 

- \n“) ; 

slm  fprintf (report_file,  "Restroom  StatlsticsinLine 
LengtRs\n") ; 

slm  fprintf  (report_f He,  :  :sim_accum_headlng() )  ; 

•  endif 

for  (1  -  0;  K-l;  i++)  ( 

Srm_schedule ( : : rest_id [ i I ,  0.0,  REPORT_EV) ; 


•  ifdef  INSTRUMENTED 
sim_wait_for (  report_reply_p,  ev); 

SIM_GET (RestroomStats,  restroom_report,  ev) ; 
rest room_report.line_length. freport (report_file) ; 
total_customers  +-  restroom_report . customers; 
total_customers_walking_away  +- 

restroom  report .cust_walkaway; 

•  endi 7 
) 

•  ifdef  INSTRUMENTED 

slm_fprintf (report_f ile,  “There  were  %5d  trips  to 
the  rest  rooms \n“, 

total_customers) ; 

sim_fprintf (report_file,  “%5d  customers  walked  away 
without  service\n“, 

total_customers_walking_away) ; 

•  endif 
//Tellers 

//sum  up  the  totals  for  the  tellers 

•  ifdef  INSTRUMENTED 

teller_totals.customer_service_time  -  my_tally (“All 
Customers") ; 

teller_totals.VIP_service_time  -  my_tally (“All 
VIPs“) ; 

teller_totals.cust_interrupts  -  0; 
teller_totals.vlp_turnaway  -  0; 
sim_fprintf  (report_file. 


- \n“) ; 

sim_fprintf (report_file,  "Teller  Service 
Reports\n“)  ; 

sim  fprintf (report_file,  : :sim_tally_headlng() ) ; 

•  endif 

for  (i  -  1;  i  <*  ::numlines;  1++)  ( 

sim_schedule (: :teller_id[l ] ,  0.0,  REPORTEV) ; 

•  ifdef  INSTRUMENTED 
sim_wait_for (  report_reply_p,  ev); 

SIM_GET (TellerStats,  teller_report,  ev); 

teller  report . customer  servicetime. freport (report_fll 
e)  ; 

teller_totals.customer_servlce_time  +- 

teller_report . oust omer_service_t ime; 

tellerreport.VIPservlcetime. freport (report_f lie) ; 
teller_totals7viP_service_time  +» 

teller  report . VIP_servlce_tlme; 
teller_totaTs.cust_interrupts  +- 
teller  report . cust_interrupts ; 

tellertotals.vipturnaway  +- 
tellerreport .vip_turnaway; 

•  endif 
I 

•  ifdef  INSTRUMENTED 

telle  r_t ot  a 1 s . customer_servi ce_t ime . freport ( report _fi 1 
e); 

teller_totals.VIP_service_time. freport (report_file) ; 
slm_fprintf  (report  file, 

"Number  of  interrupts  by  VIPs:  »d\n", 
teller_totals.cust_interrupts) ; 
sim_fprintf  (report  file, 

"Number  of  vips  turned  away  without  being 
serviced:  %d\n", 

teller_totals.vip_t urnaway) ; 

sim_fprintf  (report_file, 

- \n“); 

//sim  fprintf (report_flle,  “total_cust  -  %d  \t 
total_v!p  »  %d\n", 

//  totalcust,  total_vip); 

//sim  fprintf (report_file, 

"ave_waTting_on  queue_tlme  -  %f\n", 

//  total_queued_time/total_queued_cust) ; 

//sim  fprintf (report_fi le,  "number  of  customers  on 
lines:  5d\n", 

//  sum_line  length_stats.cust_onllne) ; 

//sim_fprintf (report_fTle,  "number  of  customers 
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visiting  rsstroom:  td\n", 

// 

sum  line  length  stats. cust_timeout) ; 

/7s im_Tpri nt  f 7report_f lie, 

//"number  of  customers  left  without  being 
serviced:  td\n", 

//sum_restroom_report.cust_walkaway) ; 

*  endif 
) 


/////////  teller. c 
•include  "teller. h" 

•include  <stdio.h> 

/* 

**  Teller  object  entity  implementation 
V 

TellerEntlty: :TellerEntity (slm  event  tev) 

( 

sim_trace (LEVEL1,  "entering  teller  entity 
constructor\n")  ; 

Tellerlnit  init  info; 

SIM_GET (Tellerlnit,  inlt_info,  ev)  ; 

ID  -  inlt_info. ID; 
customer_service_generator  - 
inlt_info.customer_service_generator; 

vip  service_generator  - 
inltTnfo. vlpservicegenerator; 

•  ifdef  INSTRUMENTED 
char  title(60| ; 

sprintf (title,  "Teller  %d  Customers", ID) ; 
stats. customerservicetime  -  my_tally(  title); 
sprintf (title,  "Teller  %d  VIPs", ID); 
stats. VIP_servlce_time  -  mytallyl  title); 

•  endif 
) 

void  TellerEntlty: :body () 

( 

simevent  ev; 

CustID  newCustomer; 

VlpID  VIP; 

GetNextEvent (  ev); 
while  (ev. typed  !-  REPORTEV)  ( 
switch  (ev. type  ()  )  ( 
case  CUSTOMER_EV: 

SIM_GET (CustID,  newCustomer,  ev) ; 

ServiceCustomer (newCustomer) ; 
break; 

case  VIP  EV: 

SIM_GET (VfpID,  VIP,  ev); 

ServlceVip(VIP) ; 
break; 
default: 

sim  error ("unexpected  event  type  »d  from:  %s\n", 
ev.type  f) , 

ev.scheduled  by ()  .named); 

) 

GetNextEvent  (  ev) ; 

) 

•  ifdef  INSTRUMENTED 
WriteReport  ()  ; 

•  endif 

slm_trace (LEVELl,  "Teller  TerminatedXn") ; 

) 

void  TellerEntlty: :GetNextEvent (sim_event  tev) 

( 

stm_schedule ( : : line_id [ ID] ,  0.0,  FREE_EV) ;  //  tell 
line  we  are  ready 

//wait  for  something 
simselect (SIMANY,  ev) ; 

If  (ev  —  SIM_NO_EVENT> 

( 

sim_trace(LEVELl,  "Waiting  for  next  customer  or 
VIP\n") ; 


sim_walt (ev) ; 

I 

) 

void  TellerEntlty: : ServiceCustomer (CustID  cuscomer) 

1 

sim_time  cust  service_time, 
service_time_remaXning; 

sim_type_p  VIP_p(VIP_EV) ; 
slm_event  ev; 

sim  trace (LEVEL1,  "handing  customer  service 
eventXn") ; 

slm  schedule (: :line_ld{ ID] ,  0.0,  BUSY_EV) ;  //prevent 
line  free-  sending  more 

•  ifdef  INSTRUMENTED 
customer. Service_Started  ()  ; 

•  endif 

cust_service_tlme  -  customer_service_generator- 
>sample  () ; 

servlce_time_remalning  -  cust_servlce_time; 

while  (  servlce_time_remaining  >  0.0) 

( 

servlce_time_remalning  » 

sim_hold_for (service_tlme_remainlng,  VIP_p, 

ev) ; 

if  (service_time_remaining  >  0.0)  //  interrupted 

by  VIP 

( 

•  ifdef  INSTRUMENTED 
stats . cust_lnterrupts++; 

•  endi f 
VlpID  VIP; 

SIMGET (VipID,  VIP,  ev); 

ServiceVip(  VIP); 
t 
I 

•  ifdef  INSTRUMENTED 

stats. customerservicetime. update ( (sim_clock ()  - 
customer. service_start) ) ; 

•  endif 

1 

void  TellerEntlty: :ServlceVlp (VlpID  ) 

f 

sim_tlme  vlpservlcetlme,  remalning_service_tlme; 
sim_type_p  newVIP_p (VIPEV) ; 

VipID  new_VIP; 
simevent  ev; 

slm  trace (LEVEL1,  “handling  vip  customer  service 
eventVn") ; 

slm_schedule (: :line  id[ID],  0.0,  BUSY_EV); 

//prevent  line  Xrorn  senuing  new  cust 

vip_servlce_time  -  vlp_service_generator->sample () ; 

remaining_service_time  -  vip_servlce_time; 
while  (  remaining_service_time  >  0.0) 

( 

remaining_service_time  - 

sim_hold_for (  remaining_service_time,  neWVIP_p, 

ev)  ; 

if  (  remainlng_service_time  >  0.0)  // 

interrupted  by  another  VIP 

I 

SIM_GET (VipID,  new_VIP,  ev) ; 

TurnAwayVipl  new_VIP) ; 

) 

I 

•  ifdef  INSTRUMENTED 

stats. VIP_service_time. update (  vip_service_tlme) ; 

•  endif 

) 
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void  TellerEntlty: :TurnAwayVip (VlpID) 

1 

«  If dal  INSTRUMENTED 

stats .  vip_t  umaaayt* ; 

#  andl  f  "" 

I 

void  TallarEntlty: :WriteReport 0 
( 

sim_trace(L£VELl,  “Writing  Teller  Report:  Teller  %d 
\n“,  ID); 

slm_schedule  (sunmary_id,  0.0, 

REPORTREPLY,  SIM_P0T (TellerStats, stats) ) ; 

) 
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APPENDIX  D 


SMALLTALK-80  CODE 


SlmulatlonObject  subclass:  (Test 
instanceVarlableNames:  '• 
classVariableNames : 
poolDlctlonaries:  * • 
category:  'Simulations* ! 

ITest  methodsFor:  'list  of  tests'! 
newt est  4 :  num 

laslm  dummy  block  I 

block  _  [dummy  <  num  ifTrue: 

[  |  myToken  I 
dummy  _  dummy  +1. 
asim  schedule:  block  at:  1. 
myToken  _  self  acquire:  1  ofResource: 

•token'. 

self  holdFor:  1.0;  release:  myTokenll. 
‘'Time  mlllisecondsToRun: 

[dummy  _  0  . 

asim  __  Simulation  new. 

asim  produce:  1  of:  'token*. 

asim  schedule:  block  at:  1  . 

asim  startup. 

[asim  proceed  -  nil)  whileFalse 
J!  ! 

!Test  methodsFor:  'list  of  tests'! 
testl:  num 

laslm  dummy | 

'■Time  mlllisecondsToRun: 

[dummy  _  0  . 

asim  Simulation  new  . 
num  times Repeat : 

[asim  schedule:  [dummy  _  dummy  +  1) 

at:  (Uniform  from:  1  to:  1000)  nextl  . 
asim  startup. 

[asim  proceed  -  nil)  whileFalse  .)!  ! 

!Test  methodsFor:  ‘list  of  tests'! 
test 2:  num 

laslm  dummy  block  I 

block  _  [dummy  <  num  ifTrue: 

[dummy  dummy  +  1. 
asim  schedule:  block  at:  1)). 

'Time  mlllisecondsToRun: 

[dummy  _  0  . 

asim  _  Simulation  new. 

asim  schedule:  block  at:  1  . 

asim  startup. 

[asim  proceed  -  nil)  whileFalse 


!Test  methodsFor:  'list  of  tests'! 
test3WithDelay:  num 

lasiml 

ATlme  mlllisecondsToRun: 

[asim  _  Simulation  new. 

asim  schedule:  (Counter  new  countWlthDelay :  num)  at:  1 
asim  startup. 

(asim  proceed  -  nil)  whileFalse 
I!  ! 

ITest  methodsFor:  'list  of  tests'! 
test3Wlth0neDelay :  num 

lasiml 

“Time  mlllisecondsToRun: 

(asim  _  Simulation  new. 


asim  schedule:  [Counter  new  countWithOneDelay :  num) 

at :  1  . 

asim  startup. 

[asim  proceed  -  nil)  whileFalse 

)!  ! 

ITest  methodsFor:  'list  of  tests'! 
test3With0utDelay:  num 

lasiml 

“Time  mlllisecondsToRun: 

[asim  _  Simulation  new. 

asim  schedule:  [Counter  new  countWlthOutDelay:  num) 

at:  1  . 

asim  startup. 

[asim  proceed  -  nil)  whileFalse 

1!  ! 

ITest  methodsFor:  'list  of  tests'! 
test4:  num 

lasiml 

“Time  mlllisecondsToRun: 

[asim  _  Simulation  new  . 
asim  produce:  1  of:  '  token'  . 
num  tlmesRepeat: 

(asim  schedule:  [Itokenl 

token  _  self  acquire:  1  ofResource:  •  token' 

self  release:  token  ) 
at:  1)  . 
asim  startup. 

[asim  proceed  -  nil)  whileFalse  .)!  ! 

!Test  methodsFor:  'list  of  tests'! 
test5:  num 

laslm  inthandl 

“Time  mlllisecondsToRun: 

[asim  Simulation  new  . 
inthand  _  InterruptHandler  new. 

asim  schedule:  [  num  tlmesRepeat:  [lnthand  handleWith 

[). 

self  holdFor:  100 
withHandler:  inthand.J) 
at :  1  . 

asim  schedule:  [  num  tlmesRepeat:  (self  holdFor:  1  . 
inthand  interrupt)) 
at :  1  . 
asim  startup. 

[asim  proceed  -  nil)  whileFalse  .)!  ! 


SlmulationObject  subclass:  ICustomerObject 

InstanceVarlableNames:  'myGender  bailout  ' 
classVarlableNames:  •' 
poolDlctlonaries:  " 
category:  'SimBenchmark* ! 

ICustomerObject  methodsFor:  'accessing'! 
getGender 


“myGender !  ! 

ICustomerObject  methodsFor:  'simulation  control'! 
getBestLine 

"return  first  available  line,  or  otherwise  line 
with  shortest  queue" 
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I  best  I 
best  _  1  . 

1  to:  NUMLINES  do:  l : Index  I 

(self  lnqulreFor:  1  ofResource:  (Index 
printstring) ) 

lfTrue;  (''index). 

((self  numWaiting:  index)  <  (self  numWaiting: 

best)) 

lfTrue:  [best  index) 

]. 

'best !  ! 

’.CustomerObject  methodsFor:  ‘simulation  control'! 
goToThePotty 

“simulate  going  to  the  potty" 

I  tolerance  resname  token  wait  I 
tolerance  _  (Gamma  mean:  2.0  var:  0.5) 
ImprovedNext . 

resname  ‘pot*  ,  (myGender  printstring). 
((((Simulation  active)  provideResourceFor: 
resname)  returnPendlngNum) 

>  tolerance) 

lfTrue:  (bailout  true] 
ifFalse: 

[token  _  self  acquire:  1  ofResource: 

resname . 

(myGender  -  0) 

lfTrue:  [wait  _  (Gamma  mean:  5.0 

var:  1.0  )  next) 

IfFalse:  (wait  _  (Gamma  mean:  3.0 

var:  1.0  )  next). 

self  holdFor:  wait  . 
self  release:  token)!  ! 

ICustomerObject  methodsFor:  ‘simulation  control*! 
numWalt lng:  index 

“return  number  waiting  on  resource  index" 

I  resource  | 

resource  _  (Simulation  active) 
provideResourceFor:  (index  printstring) . 

'resource  returnPendlngNum!  ! 

!CustomerObject  methodsFor:  ‘simulation  control1! 
tasks 

"Customer  subobject  tasks" 

I  banksim  myline  mystring  myvipstring  mytoken 
servicetime  starttime 

partialtime  pottylnthand  vlpinthand  | 
banksim  _  Simulation  active, 
pottylnthand  _  InterruptHandler  new 
handleWlth:  (self  goToThePotty). 
mytoken  _  nil. 

(mytoken  -  nll|  whileTrue: 

(bailout  lfTrue:  ['nil I. 

banksim  schedule:  [pottylnthand  interrupt) 
after:  ( (Ganna  mean:  3.0  var:  1.0)  ImprovedNext  ). 
myllne  _  self  getBestLine. 
mystring  _  myllne  printstring, 
myvipstring  ‘vlp‘  ,  mystring. 
mytoken  seXf  acquire:  1  ofResource: 
mystring  wlthHandler:  pottylnthand) . 

vlpinthand  (banksim  vipHandler:  myline) 
handleWlth: 

[partialtime  _  (banksim  time)  -  starttime, 
servicetime  _  servicetime  -  partialtime, 
self  release:  (self  acquire:  1  ofResource: 
myvipstring) ) . 

servicetime  _  (Exponential  mean:  10.0)  next  . 
starttime  _  banksim  time. 

(servicetime  >  0.0)  lfTrue:  (self  holdFor: 
servicetime  wlthHandler:  vlpinthand). 
self  release:  mytoken.!  ! 

ICustomerObject  methodsFor:  'initialization'! 
initialize 

“Initialize  instance  variables" 

myGender  _  ((RAND  next)  *  0.5)  truncated, 
bailout  false!  ! 


CustomerObject  subclass:  #VIPObJect 
instanceVariableNames :  “ 
classVariableNanves:  ‘  • 
poolDictionaries:  “ 
category:  ‘SlmBenchmark • ! 

IVIPObject  methodsFor:  ‘simulation  control’! 
tasks 

“vip  object  tasks" 

Ibanksim  myline  mystring  myvipstring  mytoken 
myviptokeni 

mytoken  _  nil. 

banksim  _  simulation  active. 

myline  _  (RAND  next  *  NUMLINES)  truncated  +  1  . 
mystring  _  myline  printstring, 
myvipstring  _  ‘vlp‘  ,  mystring. 

(self  lnqulreFor:  1  ofResource:  myvipstring) 
lfTrue:  [myviptoken  _  self  acquire:  1 
ofResource:  myvipstring) 
ifFalse:  ['nil). 

(self  lnqulreFor:  1  ofResource:  mystring) 
lfTrue:  [mytoken  _  self  acquire:  1 
ofResource:  mystringl 

IfFalse:  [ (banksim  vipHandler:  myline) 
interrupt ) . 

self  holdFor:  (Exponential  mean:  7.0)  next  . 
self  release:  myviptoken. 

(mytoken  -  nil)  ifFalse:  (self  release:  mytoken)! 


Simulation  subclass:  tBankSimulation 

instanceVariableNames:  ‘ vipIntHandlers  • 
classVariableNames:  “ 
poolDictionaries:  “ 
category:  ‘SlmBenchmark1! 

IBankSimulation  methodsFor:  ■ initialization" ! 
deflneArrivalSchedule 

“Bank  simulation  subclass  provides  the  simulation 
objects* 


2.0) 

2.0) 


self  scheduleArrivalOf :  CustomerObject 

accordingTo;  (Exponential  mean: 

scheduleArrivalOf:  VIPObJect 

accordingTo:  (Exponential  mean: 


IBankSimulation  methodsFor:  ‘initialization"! 
defineResources 

"Bank  simulation  resource  initialization" 


I  Indexstring  I 
1  to:  NUMLINES  do: 

(: index  | 

indexstring  _  index  printstring, 
self  produceT  1  of:  indexstring, 
self  produce:  1  of:  (‘vip‘  ,  Indexstring)), 
self  produce:  4  of:  ‘pot‘  ,  0  printstring; 
produce:  4  of:  ‘pot‘  ,  1  printstring.!  ! 

!BankSlmulation  methodsFor:  ‘initialization'! 
initialize 

"additional  initializations  for  Bank  Simulation" 


super  initialize. 

Transcript  show:  •  Bank  Sim  Running 

Smalltalk  at:  IRAND  put:  (Random  new). 
Smalltalk  at:  # NUMLINES  put:  3  . 
vipIntHandlers  _  Array  new:  NUMLINES. 

1  to:  NUMLINES  do: 

|:index  I  vipIntHandlers  at:  index  put: 
(InterruptHandler  new)).!  ! 

!BankSimulation  methodsFor:  ‘accessing1! 
vipHandler:  num 

"return  vip  lnt  handler  for  line  num" 
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‘viplnt Handlers  at:  nun!  ! 

Object  subclass:  ♦ RunBankSim 
InstanceVarlableNames:  " 
classVarlableNames:  • • 
poolDlctlonarles:  ' ■ 
category:  •SimBenchmark'  ! 


RunBankSim  class 

InstanceVarlableNames:  ■  •! 

'.RunBankSim  class  methodsFor:  'all'! 
time:  value 

“comment  stating  purpose  of  message* 

I  banksim  I 

bankslm  _  BankSlmulatlon  new  startup, 
(banksim  time  <  value)  whlleTrue:  (bankslm 
proceed] !  ! 
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APPENDIX  E 


MOOSE  CODE 


//////////  Test  1: 

•Include  "/va/jll/event/event.h” 
•Include  <stdllb.h> 

•Include  <ACG.h> 

•Include  <Unlform.h> 

•Include  <stream.h> 

ACG  gen; 

Uniform  r(0.0,  1000.0.  sgen); 

class  foo  ( 
public: 

void  bard  ; 

); 

foo  *f; 

class  foobarEvent  :  public  Event  f 
public: 

foobarEvent (foo  *f)  :  F(f)  (I 
private: 
foo  *F; 

virtual  void  start!)  I  F->bar();  I 

1; 

void  foo::bar()  ( 

) 

maln(lnt  argc,  char  *argv(|)  ( 
lnt  n  -  atoi (argv(l)) ; 
f  -  new  foo; 
lnit_simulatlon (n) ; 
while  (n — ) 

EVENT (foobarEvent,  (f ) ,  rill; 
run_slmulatlon() ; 
print_event_stats () ; 

HALT  () ; 


//////////  Test  2: 

•Include  "/va/jll/event/event.h" 
•Include  <stdllb.h> 

class  foo  ( 
public: 

void  bar  (lnt); 

); 

foo  »f; 

class  foobarEvent  :  public  Event  ( 
public: 

foobarEvent  (lnt  N)  :  n  (N)  (1 
private: 
lnt  n; 

void  start!)  (  f->bar(n);  I 

I; 

void  foo::bar(int  n)  ( 

If  (— n  >  0) 

EVENT (foobarEvent,  (n) ,  0.0); 


main  (lnt  argc,  char  *argv[])  ( 
lnt  n  -  atoi (argv (1 ] ) ; 
f  -  new  foo; 
inlt  simulation(n); 

EVENfl foobarEvent,  (n) ,  0.0); 
run_simulatlon()  ; 


print  event  stats (); 

//////////  Test  3a: 

•include  "/va/jil/event/event.h“ 
•include  <stdlib.h> 

class  foo  ( 
public: 

void  bar  (lnt); 

1; 

foo  *f; 

class  foobarEvent  :  public  Event  ( 
public: 

foobarEvent  (lnt  N)  :  n(N)  () 
private: 
lnt  n; 

void  start!)  (  f->bar(n);  I 

); 

void  foo::bar(int  n)  ( 
if  (--n  >  0) 
f->bar (n) ; 


main (lnt  argc,  char  *argv[|)  ( 
lnt  n  -  atoi (argv[l )) ; 
f  -  new  foo; 
init_simulation  (n) ; 

EVENT (foobarEvent,  (n) ,  1.0); 
runslmulation () ; 
print_event_stats  0 ; 


//////////  Test  3b: 

♦include  "/va/jll/event/event.h" 
•Include  <stdllb.h> 

class  foo  ( 
public: 

void  bar  (lnt); 

I; 

foo  *f; 

class  foobarEvent  :  public  Event  ( 
public: 

foobarEvent  (lnt  N)  :  n(N)  I) 
private: 
lnt  n; 

void  start  ()  (  f->bar  (n) ;  ) 

!; 

void  foo::bar(int  n)  ( 
event  delay (1.0); 

If  (— n  >  0) 
f->bar(n)  ; 


main  (lnt  argc,  char  *argv[])  ( 
lnt  n  -  atoi (argv[l)) ; 
f  -  new  foo; 
init_slmulation (n) ; 

EVENT (foobarEvent,  (n) ,  1.0); 
run_simulatlon () ; 
print_event  stats (>; 
//////////  Test  T: 
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•include  */va/jll/event/event.h“ 
•include  “/va/ j ll/event/ resource. h“ 
•include  <stdlib.h> 

class  CustomerObj  I 
public: 

void  Run  lint); 

I; 

CustomerObj  *Cust; 

Resource  *Res; 

class  RunEvent  ;  public  Event  ( 
public: 

RunEvent  (lnt  n)  :  N(n)  (( 
void  start!)  (  Cust->Run  <N) ;  I 
lnt  N; 

); 

void  CustomerObj:  .-Run  (lnt  nl  t 
If  (n  >  1) 

EVENT (RunEvent,  (n  -  1),  0.0); 
Res->glve (1) ; 
event  delay (1.0) ; 

Res->take  back(l); 

) 

main  (lnt  argc,  char  *argv(l)  ( 
lnt  1  *  atol (argv(l 1 ) ; 
lnlt_slmulatlon() ; 

Cust  -  new  CustomerObj; 

Res  *  new  Resource; 

Res->create (1) ; 

EVENT (RunEvent,  (1),  0.0); 
run_slmulation() ; 
print  eventstats () ; 

) 


//////////  Test  5: 

•Include  ”/va/Jll/event/event.h" 

•  Include  “/va/ jl  1 /'event/ interrupt  .h" 

•Include  <stdllb.h>. 

class  loo  ( 
public: 

void  Trlpper(lnt) ; 
void  Trlppee(lnt) ; 

); 

loo  *f; 

CIO  Trlppeeeld; 

DECLARE_INTERR'JPT  (Tr  1  p_I  nt e rrupt )  ; 

void  too: :Trippee(lnt  n)  ( 

for  (lnt  1-0;  1  <  n;  i*+)  I 
TRAP  eventdelay (100.0) ; 

HANDLE (Trlp_Interrupt ) ; 

END  TRAP; 

) 

) 

void  loo: :Trlpper (lnt  n)  f 

for  (lnt  1  -  0;  1  <  n;  1++)  ( 
event  delay  (1 .0)  ; 

event_lnterrupt (Trlppee  eld,  Triplnterrupt )  ; 

) 

I 

class  fooTrtppeeEvent  :  public  Event  ( 
public: 

fooTrlppeeEvent (foo  *f,  lnt  n)  :  F (f ) ,  N(n>  () 
private: 
foo  *F; 
lnt  N; 

void  start  ()  (  F->Trlppee  (N) ;  ( 

I; 

class  fooTrlpperEvent  :  public  Event  I 


public: 

fooTrlpperEvent (foo  *f,  lnt  n)  :  F(f),  N(n)  () 
private: 
foo  *F; 
lnt  N; 

void  start  ()  (  F->Tripper  (N)  ;  ) 

1; 

main (lnt  argc,  char  *argv())  { 
lnt  n  -  atol (argvll) ) ; 
f  -  new  foo; 
lnlt_slmulation(); 

EVENT (fooTrlpperEvent,  (f,n),  0.0); 

EVENT (fooTrlppeeEvent,  (f,n),  0.0); 
run_slmulation() ; 
prlnt_event_stats ()  ; 

1 


//////////  Sim  (the  bank  simulation): 

•Include  “/va/jll/event/event ,h“ 

•Include  “/va/jll/event/lnterrupt .h“ 

•include  “/va/jll/e vent/ resource. h“ 

•include  <MLCG.h> 

•Include  <£rlang.h> 

•Include  <NegatlveExpntl.h> 

•include  <DlscreteUnlform.h> 

•Include  <llmlts.h> 

•include  <stream.h> 

MLCG  randomgen; 

DlscreteUniform  rand_ger.de-  (0,  1,  srandcmgen)  ; 

Erlang  rand_nature (1 .0,  1.0,  srandomgen); 

//  change  params  later  to  meanNatureCallsTime  and 
varianceNatureCallsTime 

Erlang  rand_llne(1.0,  1.0,  trandomgen) ; 

//  change  params  later  to  mea-LineTolerance  and 
varlanceLineTolerance 

Erlang  rand_frest (5.0,  8.0,  trandomgen); 

Erlang  rand_mrest (3 .0,  6.0,  trandomgen); 

DlscreteUniform  rand_numllnes (0,  1,  trandomgen); 
//  change  max  to  numLines  -  1 

Erlang  rand_serve (1 .0,  1.0,  trandomgen); 

//  change  mean  later  to  meanServiceTime, 
varlanceServiceTime; 

NegatlveExpntl  rand_custarrlve (1.0,  trandomgen); 
//  change  mean  later  to  meanlnterArrlveTime 

NegatlveExpntl  rand_viparrlve (1 .0,  trandomgen); 

//  change  mean  later  to  meanVIPInterArrlveTlme 


enum  Gender  (Female,  Male); 

class  LineObj  :  public  Resource  ( 
public: 

class  CustomerObj  ‘serving; 

EID  service  eld; 

void  ServeCust  (class  CustomerObj  ‘cust) ; 

); 

typedef  LineObj  ‘LlneObjP; 

class  ServeCustEvent  :  public  Event  ( 
public: 

ServeCustEvent (LineObj  *1,  CustomerObj  *c)  : 
L(l),  C  (c)  |) 

void  start (|  (  L->Se rveCust (C) ;  ) 
private: 

LineObj  *L; 

CustomerObj  *C; 

); 
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typedef  Resource  RestRoom; 

class  CustomerObj  ( 
public: 

Gender  myGender; 

CustomerObj  0 ; 
virtual  void  GetOnLlneO; 
void  VisitFacllitles  () ; 
virtual  Int  isVIPO  I  return  0;  ( 
private: 

LineObj  ‘FindBestLine ()  ; 

); 

class  GetOnLlneEvent  :  public  Event  ( 
public: 

GetOnLlneEvent  (CustomerObj  *c)  :  C(c)  (( 
void  start!)  (  C->GetOnLlne () ;  ) 
private: 

CustomerObj  *C; 

); 

class  VIPObj  :  public  CustomerObj  1 
public: 

void  GetOnLlneO; 

lnt  lsVIPu  (  return  1;  ( 

I; 

class  CustGenerator  :  public  Event  1 
protected: 

Negat  tveExpnt 1  * inter Arrive ; 

virtual  void  newCust  ()  (  CustomerObj  *co  -  new 
CustomerObj;  ) 
public: 

CustGenerator 0  :  InterArrive (irandcustarrive) 

0 

void  start  ()  ; 

); 

class  VIPGenerator  :  public  CustGenerator  ( 
protected: 

virtual  void  newCust  0  (  VIPObj  *vo  -  new  VIPObj; 

) 

public; 

VIPGenerator (I  |  InterArrive  «  srand  vlparrlve;  ) 

); 

CustomerObj: :CustomerObj ()  ( 

myGender  -  rand_gender 0 ; 

EVENT (GetOnLlneEvent,  (t)us) ,  0.0); 

I 

DECLARE_INTERRUPT(Nature_Calls_Interrupt) ; 

class  NatureCallsEvent  :  public  Event  { 
public: 

NatureCallsEvent {)  {  eid  -  Current_EID {) ;  ) 
void  start  0  {  event_interrupt {eid, 
Nature_Calls_Interrupt) ;  } 
orivate: 

EID  eid; 

); 

double  hoursToRun; 
double  meanlnterArriveTime; 
double  mea nVI Pinter ArriveTi me; 
double  meanNatureCallsTime; 
double  varianceNatureCallsTime; 
double  meanLineTolerance; 
double  varianceLineTolerance; 
double  meanServiceTime; 
double  varianceServiceTime; 
int  numLines; 

LineObj  **allLines; 

RestRoom  * rest Rooms [2 1 ; 
long  seed; 

’ nt  numCusts  -  0; 
int  numVips  -  0; 
int  numCustLeaving  -  0; 
int  numMadVips  =  0; 
int  numNatureCalls  ^  0; 
int  numVipInterrunts  *  0; 


Sim_Time  totalTimeUntilServed  -  0.0; 

Sim_Time  totalCustServiceTime  -  0.0; 

void  CustomerObj : : Get On Line ()  { 

LineObj  *myLlne; 

Sim_Time  timeTillNatureCalls; 

//  numCusts++; 

EID  timeout; 

Sim_Time  time  -  simulat longtime () ; 

for  < ; ; )  { 
for  (;;)  { 

timeTillNatureCalls  -  rand_nature 0 ; 
myLine  -  FindBestLine () ; 
timeout  -  EVENT (NatureCallsEvent,  0, 
timeTillNatureCalls) ; 

TRAP  { 

myLine->give (1) ; 
break; 

)  HANDLE (Nature_Cails_Interrupt) 
VisitFacllitles () ; 

ENDJTRAP; 

) 

totalTimeUntilServed  ♦-  simulation_time ()  - 

time; 

event ^terminate (timeout) ; 

//  time  -  simulation  time{); 
myLine->ServeCust (thTs) ; 

//  totalCustServiceTime  +«  simulation_time ()  - 

time; 

myLine->take_back  (1) ; 
break; 

) 

delete  this; 

} 

void  CustomerObj: :VisltFacilities {)  ( 

RestRoom  *restRoom; 

int  restRoomLineTolerance; 

//  numNatureCalls++; 
restRoom  -  restRooms (myGender) ; 
restRoomLineTolerance  -  lnt (rand  line  ()  ♦  0.5); 
if  (rest Room- >num _pending  ()  > 
restRoomLineTolerance)  { 
delete  this; 

//  numCustLeaving++; 
event _terminate () ; 

)  else  ( 

restRoom->give(l) ; 

eve nt_del ay ( (myGender  —  Female)?  rand_frest() 
rand_mrest  (f)  ? 

~  restRoom->take_back  (1)  ; 

) 

} 

LineObj  *CustomerObj: : FindBestLine {)  { 

LineObj  *line,  *bestLine; 
int  length,  bestLength; 

best Length  -  INT  MAX; 
for  (int  i  -  0;  T  <  numLines;  i++)  { 
line  -  allLines[i); 
length  -  line->num_pending () ; 
if  (line->available ()  -«  0)  length**; 
if  (length  <  bestLength)  { 
bestLength  -  length; 
best Line  -  line; 

) 

I 

r^Lirn  bestLine; 

I 

DECLARE_INTERRUPT (VIP_Arrives_Interrupt ) ; 
DECLARE_INTERRUPT (VIP_Leaves_Interrupt ) ; 

void  VIPObj: :GetOnLine{)  { 

LineObj  *line; 

CustomerObj  *oldCust; 

//  numVips**; 

int  nline  -  int (rand_numlines  () ) ; 
line  -  allLinrs (nline) ; 
oldCust  -  line->serving; 
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EID  oldservice  -  line->service  eid; 
if  (oldCust)  ( 
if  (oldCust->isviP o )  ( 

//  numMadVips++; 
return; 

} 

//  numVipInterrupts++; 
event_interrupt (oldservice, 
VIP_Arrives_Interrupt) ; 

~  }  else 

line->give (1)  ; 
line->ServeCust  (this) ; 
if  (oldCust) 

event_interrupt (oldservice, 
VIP_Leaves_Interrupt ) ; 

~  else 

line->take__back  (i) ; 
delete  this;- 


void  LineObj: :ServeCust (CustomerObj  *cust)  ( 

Sim_Time  svcTime,  startTime; 

svcTime  «  rand_serve () ; 
for {;; )  ( 

service  eid  *  Current_EID() ; 
startTime  =  simulat  ion_t  ime  () ; 
serving  »  cust; 
if  (svcTime  <=  0,0) 
break; 

TRAP  ( 

event_delay  (svcTime) ; 
serving  -  0; 
break; 

)  HANDLE (VIP_Arrives  Interrupt)  ( 

svcTime  —  simuIation_t ime  ()  -  startTime; 
TRAP  event_suspend () ; 

HANDLE (VIP_Leaves_Interrupt) ; 

END  TRAP; 

)  END_TRAP; 

) 


void  CustGenerator : rstart ()  ( 

CustomerObj  ‘customer; 

Sim  JT  ime  waitTime; 

for  (;;)  ( 

waitTime  -  (• interArr i ve) () ; 
event_delay  (waitTime) ; 
newCust  () ; 

I 

) 

class  EndSirr  :  public  Event  • 
public: 

void  start  ()  i 
print_event_stats () ; 

HALT  ()  ; 

I 

l; 

main  0  1 

rest Rooms [ Fema *e )  *  new  Rest  Room; 
rest Rooms [Male  I  =  new  Rest  Room; 
rest Rooms [Fema le ! ->creat e  (4 ) ; 
rest  Rooms (Male : -> create (4 i ; 

cout  <<  "C-  •  Simulation  'Lines  ana  Rest  Rooms' 
starting  —  \nH; 

cout  <<  “What  is  the  near  customer  : nterar r i va 1 
time  in  minutes? 

cin  >>  meanlnterAr r i veTime; 
rand  cust a r rive. mean (reanlnterArriveTime) ; 
cout~<<  "What  is  the  mean  VIP  interarrival  time 
in  minutes? 

cin  >>  meanVI P In?. er Ar r iveTime; 
rand  v ipa rr ; ve . mean  (meanVI PI nt erAr r i veT ime) ; 
cout”<<  "What  is  tne  mean  service  time  in 
minutes? 

cin  >>  mearServi ceT ire; 

rand  serve .mean (mearServ : ceT .me) ; 


cout  «  “What  is  the  variance  of  the  service 

time? 

cin  »  varianceServlceTime; 
rand_serve. variance (varianceServlceTime) ; 
cout  «  “What  is  the  mean  time  in  minutes  till 
‘Nature  Calls'?  “; 

cin  »  meanNatureCallsTime; 
rand_nature.mean (meanNatureCallsTime) ; 
cout  «  “What  is  the  variance? 
cin  >>  varianceNatureCallsTime; 
rand_nature. variance (varianceNatureCallsTime) ; 
cout  «  “What  is  the  mean  restroom  line  length 
tolerance?  “; 

cin  »  meanLineTolerance; 

rand_line.mean (meanLineTolerance) ; 

cout  «  “What  is  the  variance? 

cin  »  varianceLineTolerance; 

rand_line. variance (varianceLineTolerance) ; 

cout  «  “How  many  lines  are  there?  "; 

cin  »  numLines; 

rand_numlines.hlgh (numLines-1) ; 

cout  «  “How  many  hours  should  the  simulation 

run? 

cin  »  hoursToRun; 
cout  «  “Random  Seed?  “; 
cin  »  seed; 

cout  <<  “XnMean  Interarrive  Time:  “  « 
meanlnterArr iveTime  «  “\n“; 

cout  «  “Mean  VIP  Interarrive  Time:  “  « 
meanviP InterArr iveTime 
«  “\n“; 

cout  «  “Mean  Service  Time:  “  «  meanServiceTime 
«  “\n“; 

cout  «  “Variance  Service  Time:  “  « 
varianceServlceTime  «  “\n"; 

cout  «  “Mean  'Nature  Calls'  Time:  “  « 
meanNatureCallsTime  «  **\n"; 

cout  «  “Variance  'Nature  Calls'  Time:  "  « 
varianceNatureCallsTime  «  “\n“; 

cout  «  “Mean  line  length  tolerance:  "  « 
meanLineTolerance  «  “\n“; 

cout  <<  "Variance  line  length  tolerance:  “  « 
varianceLineTolerance  <<  “\n"; 

cout  <<  “Number  of  lines:  “  <<  numLines  «  "\n"; 
cout  <<  “Hours  to  run:  “  <<  hoursToRun  «  “\n“; 

aliLines  -  new  LineObjP [ numLines) ; 
for  (int  k  *  0;  k  <  numLines;  k++)  ( 

LineObj  ‘line  *  new  LineObj; 
line~>create (1) ; 
allLines[k]  =  line; 

) 

randomgen. reseed (seed,  seed); 

init_simulation (4000,  2000); 

EVENT (EndS im, ,  hoursToRun  *  60.0); 

EVENT (CustGenerator,  (),  0.0); 

EVENT (VIPGenerator,  0,  0.0); 

rur_simulat ion  { ) ; 

/• 

cout  <<  numCusts  <<  “  customers  arrived. \n“; 
cout  <<  numVips  <<  “  VIPs  arrived. \n"; 
cout  <<  numMadVips  <<  "  VIPs  left  angrily. \n“; 
cout  <<  “There  were  "  <<  numNat ureCal Is  «  " 
visits  to  the 
rest  rooms . \n"; 

cout  <<  numVipInterrupt s  «  "  customers  were 
interrupted  by  VIPs.\r“; 

cout  <<  numCustLeaving  <<  "  customers  left 
without  being  served. \r.m; 

cout  <<  "The  average  customer  service  time  was  " 

« 

totaiCust terv i ceTime  /  (numCusts  - 
numCustLeaving)  << 

cout  <<  “The  average  customer  wait  time  was  “  << 
t ota IT imeUr.:  i  1  Served  /  (r.umCust s  - 
numCust Leavi ng)  <<  “\n"; 
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for  (k  -  0;  k  <  numLines;  k++)  { 
cout  «  “\nThe  statistics  for  the  length  of 
line  #••  «  k+1  « 

•  are:\n“; 

allLines [k] -> repo rt_s tats () ; 

I 

cout  «  “\nThe  statistics  for  the  length  of  the 
mens  room  line 
are: \n"; 

restRooms(Male]->report_stats  {) ; 

cout  «  "\nThe  statistics  for  the  length  of  the 
ladies  room  line 
are:\n"; 

restRooms (Female) -> report _st at s () ; 

*/ 

print  event  stats (); 

} 


APPENDIX  F 


ERIC  CODE 


;;;  testl 

(define-class  Nothing  (:parents  Something)) 

(ask  Nothing  when  receiving  (bar)  nil) 

(delun  testl  (n) 

(declare  (type  f lxnum  n) ) 

(ask  Nothing  make  instance  foo) 

(dotlmes  (1  n) 

(declare  (type  flxnum  11) 

(ask  clock  to  schedule  (foo  to  (bar) 
at  ! (random  1000) ) ) 

(ask  clock  run  to  completion)) 

(defvar  'Nothings*) 

(defun  testla-internal  (n) 

(declare  (type  flxnum  n) ) 

(do  -ties  (1  n) 

(declare  (type  flxnum  1 ) ) 

(let  ((x  (svref  ‘nothings*  1))) 

(ask  clock  to  schedule  !x  to  (bar)  at 
! (random  1000) ) ) ) 

(ask  clock  run  to  completion)) 

(defun  testla  (n) 

(let  (('nothings*  (make-array  n))) 

(dotlmes  (1  n) 

(setf  (aref  'nothings*  1)  (ask  Nothing 
make  instance  foo) ) ) 

(time  (testla-internal  n) ) ) ) 

;;; test2 

(define-class  Nothing  (:parents  Something)) 

(ask  Nothing  when  receiving  (bar  >m) 

(if  (>  m  1)  (ask  clock  to  schedule  (self  to  (bar 
! (decf  m) )  at  0) ) ) 

(defun  nextbaz  (n) 

(declare  (type  flxnum  n) ) 

(If  (>  n  1) 

(let  ( (n-1  (1-  n) ) ) 

(declare  (type  flxnum  n-1) ) 

(ask  clock  to  schedule  ! foo  to  (baz  ! n-1)  at 

0)))) 

(ask  Nothing  when  receiving  (baz  >n) 

(nextbaz  n) ) 

(defun  test2  (n) 

(declare  (type  flxnum  n) ) 

(ask  clock  set  your  simtime  to  0) 

(ask  Nothing  make  instance  foo) 

(ask  clock  to  schedule  ! foo  to  (bar  !n)  at  0) 
(ask  clock  run  to  completion)) 

;; ;test3a 

(define-class  Nothing  (:parents  Something)) 

(pci ;defmethod  barl  ((self  Nothing)  n) 

(when  (plusp  (decf  n) ) 

(barl  self  n) ) ) 

(ask  Nothing  when  receiving  (bar  >n) 

(decf  n) 

(barl  self  n) ) 

(defun  test3a  (n) 

(declare  (type  flxnum  n) ) 


(ask  clock  set  your  simtime  to  0) 

(ask  Nothing  make  instance  foo) 

(ask  clock  to  schedule  (foo  to  (bar  !n)  at  0) 

(ask  clock  run  to  completion)) 

;;;test3b 

(define-class  Nothing  ((parents  Something)) 

(pci (defmethod  barl  ((self  Nothing)  n) 

(declare  (type  flxnum  n) ) 

(when  (plusp  (decf  n) ) 

(ask  clock  to  schedule  (self  to 
(complete-bar  !n)  in  1  second))) 

(ask  Nothing  when  receiving  (bar  >n) 

(barl  self  n)) 

(ask  Nothing  when  receiving  (complete-bar  >n) 

(barl  self  n) ) 

(defun  test3b  (n) 

(declare  (type  flxnum  n) ) 

(ask  clock  set  your  simtime  to  0) 

(ask  Nothing  make  instance  foo) 

(ask  clock  to  schedule  (foo  to  (bar  !n)  at  0) 

(ask  clock  run  to  completion)) 

; ; ;test4 

(define-class  Nothing  (:parents  Something)) 

(ask  Nothing  when  receiving  (run  >n) 

(when  (>  n  1) 

(ask  clock  to  schedule  (self  to  (run  ! (1-  n) ) 
in  0  seconds) ) 

(ask  res  give  1  and  ask  (self  run2  ! n ) ) 

(ask  Nothing  when  receiving  (run2  >n) 

(ask  clock  to  schedule  (self  to  (run3  ! n)  in  10 
seconds) ) 

(ask  Nothing  when  receiving  (run3  >n) 

(ask  res  take-back  1)) 

(defun  test4  (n) 

(declare  (type  flxnum  n) ) 

(ask  resource  make  instance  res) 

(ask  res  create  1) 

(ask  Nothing  make  instance  cust) 

(ask  clock  to  schedule  (cust  to  (run  ! n)  in  0 
seconds) 

(ask  clock  run  to  completion)) 
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